Subject: Re: Linker (ld) seems to ignore certain LDFLAGS during configure
To: Klaus Heinz <k.heinz.feb.fuenf@onlinehome.de>
From: Eric Boutilier <Eric.Boutilier@Sun.COM>
List: tech-pkg
Date: 02/18/2005 18:15:50
Aha! Great explanation -- thanks!

Eric

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/.
>
> ciao
>      Klaus
>