math/blas linking to gfortran with LDADD?= -lgfortran
b. f.
bf1783 at googlemail.com
Tue Aug 31 19:06:34 UTC 2010
>The subject listed port fails to link during an upgrade from the
>previous version. Looking into this further libblas.so.2 without being
Would you elaborate, please? Where is a transcript showing the linking failure?
Would you mail it to me off-list?
>linked to gfortran is correct as in the already installed previous
>version installed inspected with ldd(1) shows the same linking as the
>new version without the -lgfortran linker flags.
>
I don't find this to be the case. Perhaps you could provide listings for
`ldd -a /usr/local/lib/libblas.so.2`, `objdump -x
/usr/local/lib/libblas.so.2`, and
`make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and
without your change, off-list?
>Attached is the patch that solves the linking problem. I do not see any
>dependents listed for this port for any of the gcc* ports that can be
>installed so therefore I have removed the -lgfortran from LDADD.
? USE_FORTRAN=yes ==> USE_GCC=4.4
You don't see any relevant undefined symbols in the blas libraries?
With regards to your statements about math/lapack and profiling: it
has been the case for some time that this port has built and installed
these libraries by default, perhaps because this port has mainly been
used by people concerned about numerical linear algebra and concrete
measures of performance. I recently added the statement you quoted to
allow users to avoid these libraries -- it intentionally mirrors the
similar statement in the allied port math/blas, where the form is is
dictated by the use of bsd.lib.mk to build the libraries. Given the
typical use of these ports, I don't think it is unreasonable to enable
profiling libraries by default. But if you don't like it, you can now
easily opt out.
Regards,
b.
More information about the freebsd-ports
mailing list