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

[Andy Wingo]

Hi Jan,

Apologies for the delay in the reply.

On Thu 24 Feb 2011 10:39, Jan Nieuwenhuizen <address@hidden> writes:

> Andy Wingo schreef op di 22-02-2011 om 09:34 [+0100]:
>
>> To be honest I don't find it too onerous to have to set these flags when
>> compiling with DESTDIR.  Sure, it would be nicer if it were just one
>> flag, and perhaps we can fix that; but as you have perhaps seen in the
>> numerous discussions on bug-guile recently, it seems that
>> AC_LIB_HAVE_LINKFLAGS solves real problems.
>
> I'm glad to hear that, at least it means that my cross build troubles
> were for a good cause...  So now I need to look into the problems
> that AC_LIB_HAVE_LINKFLAGS actually solves and see how to keep solving
> them while not breaking zero-config DESTDIR-builds.

Here is my understanding of the problems and solutions.

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 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.

That's the problem that AC_LIB_HAVE_LINKFLAGS solves for normal
"configure && make && make install" users.  It can complicate $DESTDIR
builds a little, in that you have to add some more configure arguments,
but it's not that bad.

Peace,

Andy
-- 
http://wingolog.org/