[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14
From: |
Jan Nieuwenhuizen |
Subject: |
Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw] |
Date: |
Sun, 20 Mar 2011 09:08:20 +0100 |
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 <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.nl