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 <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
