Subject: Re: Linker (ld) seems to ignore certain LDFLAGS during configure
To: Klaus Heinz <firstname.lastname@example.org>
From: Eric Boutilier <Eric.Boutilier@Sun.COM>
Date: 02/18/2005 18:15:50
Aha! Great explanation -- thanks!
On Sat, 19 Feb 2005, Klaus Heinz wrote:
> Eric Boutilier wrote:
> > I'm perplexed by a problem where a configure script is not able to
> > find a library. The error message is:
> > ld: fatal: library -lcrypto: not found
> > As a result, the package (curl) gets built w/out SSL support.
> > I'm trying to make the build find the libcrypto.so library which,
> > on Solaris 10, resides in /usr/sfw/lib.
> > I've tried to troubleshoot the problem but I'm still stumped. The
> > LDFLAGS are set properly (see below) to include:
> > -L/usr/sfw/lib -Wl,-R/usr/sfw/lib
> > And in order to confirm that this setup should work, I copied the
> > compile command and flags verbatim out of config.log (copied below)
> > and ran it manually from a command line. When I do that, it
> > compiles (finds libcrypto.so) just fine.
> > Very weird... at least for me. :-/
> Pkgsrc tries very hard _not_ to let packages pick up arbitrary installed
> files/libraries from the system where it is used to build packages from
> source. To this end, pkgsrc uses a set of wrapper scripts for programs
> like gcc, as, ld to sanitize the options the real compiler or linker
> sees. This way, the toolchain only uses header files or libraries having
> a symlink under pkgsrc/<category>/<package>/work/.buildlink/.
> You can see this when you build a package:
> $ make
> ===> Creating toolchain wrappers for spamassassin-3.0.2nb1
> This also enables pkgsrc to support native toolchains (like Forte/SunOne):
> the wrapper framework rewrites options for gcc, which most Makefiles
> support, into options for the native compiler.
> If a pkgsrc Makefiles needs a certain package as a prerequisite, it
> includes the needed ../../<prerequisite_pkg>/buildlink3.mk file, which
> creates the necessary symlinks under work/.buildlink/. If there is a
> native version (eg, native OpenSSL), there is also a
> ../../<prerequisite_pkg>/builtin.mk that is then automatically included.
> This file checks whether the native version fulfills all requirements
> (eg, a certain patch level of OpenSSL). After this check, the
> builtlink3.mk file creates the necessary symlinks, either to
> the native files, or to the files from the pkgsrc package (under LOCALBASE,
> usually /usr/pkg/).
> In the case of your libcrypto.so, the wrappers stripped the LDFLAGS you
> supplied off the list of parameters the real linker effectively used.
> This explains, why it worked when you manually executed the compile
> command from the config.log file: you did what "configure" _assumed_ to
> do in config.log but what was really done by the wrapper scripts can be
> seen in work/.work.log. Lines marked [*] are the original, and after
> some intermediate steps lines marked with <.> are actually executed.
> So, in order to use libcrypto.so from the base system, you need to
> depend on OpenSSL and security/openssl/builtin.mk needs to
> recognize the native OpenSSL files on Solaris. When this is done, the
> real compiler/linker will see the linker flags and the native library will
> have a symlink under work/.buildlink/lib/.