math/blas linking to gfortran with LDADD?= -lgfortran

b. f. bf1783 at
Wed Sep 1 00:06:39 UTC 2010

On 8/31/10, jhell <jhell at> wrote:
> On 08/31/2010 15:06, b. f. wrote:
>> Would you elaborate, please?  Where is a transcript showing the linking
>> failure?
>> Would you mail it to me off-list?
> Simply -lgfortran by it self should not work. Since lib directories
> gcc44 gcc45 gcc46 and such are not in the standard path
> -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for
> it to be found.
> Off list should not be necessary.

? gfortran44 builds the object files, and gcc44 performs the linking
for the shared library.  Their default search directories normally
allow them to find libgfortran at compile- and link-time.  And
afterwards, at run-time, the appropriate rpath is inscribed in the
binary (see this has been done for some time now),  if the
system linker hints aren't sufficient.  So this does not seem to
explain your problem, and that's why I asked for more complete
information.  Since I don't want to spam the list with that volume of
material, that's why I asked for it to be sent via private email.

> With my change in objdump the only thing listed in objdump -x that is
> relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no
> undefined symbols.

As I said before, I cannot account for this -- I really need to see
the complete information I requested earlier.  Since gfortran44 is
used to build the library components, there should be undefined
symbols relating to libgfortran in all of the libraries, and the rpath
should be present in both cases, if all you did was remove the
explicit libgfortran from LDADD.  The only difference should be the
presence or absence of a DT_NEEDED tag for libgfortran.

> Would it be possible with this to check for the existence of -lc_p
> before and opt out automatically while warning the user that the
> profiled libc was not found so profiling will be unavailable. ?

I'll look into this.  There is a dichotomy here:  when building from
source, base system profiling libraries are built and installed by
default.  The same may not be true if the user installs a binary
distribution, using something like systinstall(8).  It should be
possible to handle both cases.

On your subsequent question about the form of the statement: for
math/lapack, yes, the statement could be changed to fit into the
OPTIONS framework.  But, as I wrote before, I put it in that form to
mimic the similar statements in math/blas.  The statements in
math/blas must take into account the NO* variables,  and
WITHOUT_PROFILE, because the presence of these variables in the build
environment or an included makefile is what actually controls whether
the profiling libraries are built, via the relevant base system
makefiles in /usr/share/mk, regardless of WITH_PROFILE. I will look
into using the OPTIONS framework -- in the base system makefiles,
unlike in Ports, there is a sanity check on the simultaneous use of
WITH_FOO and WITHOUT_FOO.  So there are some added safeguards, not
normally available for Ports, that may make it possible to integrate
this with OPTIONS.


More information about the freebsd-ports mailing list