Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]

[Jan Nieuwenhuizen <janneke-list@xs4all.nl>]

Andy Wingo schreef op vr 04-03-2011 om 12:11 [+0100]:

Hi Andy,

[sorry for the long quote]

> Let's say you are building and installing Guile on Fedora.  You download
> the tarball, ./configure && make && make install, and voila.  You run
> Guile and it works.  Sweet!
> 
> So now you follow the manual, and it says that you can build your own
> Guile via:
> 
>  $ gcc -o simple-guile simple-guile.c $(pkg-config guile-2.0 --cflags --libs)
> 
> which in your case expands out to
> 
>  $ gcc -o simple-guile simple-guile.c -I/usr/local/include/guile/2.0 -L/usr/local/include -lguile-2.0
> 
> And it compiles and links.  Awesome.
> 
> However when you run the simple-guile it doesn't work:
> 
>  $ ./simple-guile
>  error: could not find libguile-2.0.so
> 
> Why is this?  It's because in Fedora, /usr/local/lib is not in the
> default runtime library search path.
> 
> If we were compiling on Debian this would work because /usr/local/lib is
> in the default library search path, though we would see the issue if we
> installed to (e.g.) /opt/guile.
> 
> If we were compiling on Mac OS X it would work fine because the linker
> effectively adds -rpath for libraries not in the standard locations
> (even the /opt/guile case).
> 
> Those of us that haven't linked anything on the command line in a while
> probably haven't noticed, because we use libtool to do the linking, and
> libtool will add -rpath when linking against libraries that are not in
> your system run path.
> 
> It used to be that libtool always added -rpath, but distros complained
> -- Debian for one -- and so now libtool only adds -rpath for libs that
> are not going to a system path.
> 
> It seems that what libtool does is the right thing to do by default.
> The problem is, you can't add the -rpath in guile-config or pkg-config
> -- the right thing to do depends on the compiler you are using.  So you
> have to check for that at configure-time.  That's what
> AC_LIB_HAVE_LINKFLAGS does.  Given some link-time flags,
> AC_LIB_HAVE_LINKFLAGS determines what flags will be needed such that the
> library will be found at runtime.  It adds -rpath when linking against
> libraries that are not in your system path.

This all makes perfect sense to me.  Thanks for the elaborate
explanation.

> This discussion about system paths usually includes /usr, so that's the
> default behavior of AC_LIB_HAVE_LINKFLAGS.  But sometimes you don't want
> AC_LIB_HAVE_LINKFLAGS to look there -- that is, when you have $DESTDIR
> builds -- and so in that case there are all those
> --without-PACKAGE-prefix arguments.

Right.  So, while AC_LIB_HAVE_LINKFLAGS breaks $DESTDIR compiles (from
a AC_CHECK_LIB-pov) by default, even those will work by the aid of
these extra options.

Now consider, I have ~250 packages in my small cross build suite
and I imagine that projects like openembedded have a factor 10 more.
If/when AC_LIB_HAVE_LINKFLAGS becomes more popular, every of these
packages needs its configure be amended with --with-libFOO-prefix=...,
--with-libBAR-prefix=...  While doable, it would be nice if this
could be prevented.

What is not clear to me, from your explanation above, is why
AC_LIB_HAVE_LINKFLAGS needs to look in /usr at configure/build 
time, and especially: why it needs to look in /usr before looking
in gcc's library search path.

If it only looked in /usr after looking in the library search path,
the impact on $DESTDIR builds would be smaller: only --without-libFOO
would have to be specified.

It would be nicer still if looking in /usr at compile/build time could
be turned off (from your use cases that seems to be possible), or
be turned off for $DESTDIR builds.  That could be done with a single
flag.  It would be perfect if we found a way to detect $DESTDIR
builds automagically, so that the --with/--without $DESTDIR option
would have a smart default.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl