Date: Wed, 1 Sep 2010 00:06:26 +0000 From: "b. f." <bf1783@googlemail.com> To: jhell <jhell@dataix.net> Cc: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: math/blas linking to gfortran with LDADD?= -lgfortran Message-ID: <AANLkTinv-D1iQSxeRVMW5XjALYGx8NyJ0jcdJugVD58q@mail.gmail.com> In-Reply-To: <4C7D70CA.2070104@DataIX.net> References: <AANLkTinhAPY-PEH_TegMAEx1ejHf_WoEL8KZU%2BoXGhFD@mail.gmail.com> <4C7D70CA.2070104@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/31/10, jhell <jhell@dataix.net> 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 bsd.gcc.mk: 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. b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinv-D1iQSxeRVMW5XjALYGx8NyJ0jcdJugVD58q>