attempting to resucitate Lahey Fortran port

Alexander Leidinger Alexander at Leidinger.net
Thu Mar 4 16:09:46 PST 2004


On Thu, 4 Mar 2004 15:49:10 -0500
"Dr. Richard E. Hawkins" <hawk at slytherin.ds.psu.edu> wrote:

> > > >> MASTER_SITES=   # fetch manually  
> 
> > > >You don't tell us where to get it from. 
> 
> > > Which makes no sense for an installer for a commercial linux project.
> 
> > But you used "fetch manually"... I think it would be better to use
> > "comes on CD" or something like this. I haven't reopened the PR, because
> > of your problems below.
> 
> OK, I'll switch that.  But I think it's what the guide said to do at the time.

It's mostly a recommendation, it's up to the porter to choose an
appropriate way of doing things.

> > > slytherin ttyp6:dpt>lf95 dpt1.f95
> > > Encountered 0 errors, 0 warnings in file dpt1.f95.
> > > /usr/bin/ld: unrecognised emulation mode: elf_i386
> > > Supported emulations: elf_i386_fbsd
> 
> > > What does this mean/how do I fix it?
> 
> > If you can't change the emulation in lf95, you may perhaps have to write
> > a ld wrapper which replaces the emulation. We have something like this
> > in the icc and ifc ports (not for changing the emulation, but for other
> > things).
> 
> A vague bell rang in my memory, and I installed the linux_devtools port.
> That solved it, although the output of "ld -V" didn't change.  My

This way you install an linux ld binary into /compat/linux. Programs
which run in the linux compatibility environment first see files in
/compat/linux, and only if the file can't be found there the linux
program will see the files in the real FreeBSD environment. So lf95 sees
/compat/linix/usr/bin/ld now and uses it, whereas it has used
/usr/bin/ld before you installed the linux_devtools port because the
/compat/linux one wasn't there.

> makeefile has the lines,
> 
> RUN_DEPENDS= /compat/linux/lib/libc.so.6:${PORTSDIR}/devel/linux_devtools
> FETCH_DEPENDS= ${LINUXBASE}/lib/libc.so.6:${PORTSDIR}/devel/linux_devtools

This has several drawbacks:
 - libc.so.6 is a library, so LIB_DEPENDS should be used
   (but you don't need to, as USE_LINUX=yes already satisfies the
   libc.so.6 dependency)
 - libc.so.6 doesn't get installed by linux_devtools, so this is wrong
 - linux_devel doesn't contain anything which is needed to fetch
   a component of the port, so FETCH_DEPENDS is wrong

> This doesn't cause the devtools to be installed, nor does it cause an
> error.

I would use
 RUN_DEPENDS= ${LINUXBASE}/usr/bin/ld:${PORTSDIR}/devel/linux_devtools

Note: I haven't verified if the path to ld is the right one.

This way you use the linux ld to link a program, so it will be an linux
binary, not a FreeBSD binary. I don't know if this is intended. If you
didn't have some special fixes like we have in the ifc and icc ports, I
assume depending on linux_base is the right way to solve this issue.

> Also, the linux and linux_devtools seem to be a moving target.  What is
> the correct way to make the appropriate dependency?

The default linux emulation is based upon the v7 ports (since a long
time), so you should use the v7 linux_devtools port. If your port
depends upon another linux_base version, it also needs to depend on a
similar linux_devtools port.

> Hmm, and my digging has lead to a new question.  There is now a
> linuxthreads port.  Will this let multi-threaded linux applications run?
> If so, it should be a dependency (lf95 can make multithreaded, but they
> can't run with just devtools.  The port-descr says:
> 
> >LinuxThreads is an POSIX pthreads implementation using "kernel threads".  In
> >this FreeBSD port, a kernel thread is started using rfork (whereas in the
> >original Linux implementation a kernel thread is started using the Linux clone
> >call).  This implementaion provides a so-called one-to-one mapping of threads to
> >kernel schedulable entities. For more information see about the original

linuxthreads is a FreeBSD library. It does threading similar to the way
linux does it. So if your port doesn't produce native FreeBSD
executables (because you don't do nasty tricks like the ifc and icc
ports do), you can't use it. I think you need to lookup a linux pthreads
lib somewhere. I can't give a better advise, as I don't know how lf95
fails in this regard.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


More information about the freebsd-ports mailing list