Hi Jan, Apologies for the delay in the reply.
On Thu 24 Feb 2011 10:39, Jan Nieuwenhuizen <janneke-l...@xs4all.nl> 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/
