[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for
problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]
Fri, 04 Mar 2011 12:11:20 +0100
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
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
$ 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
And it compiles and links. Awesome.
However when you run the simple-guile it doesn't work:
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
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.
- problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw],
Andy Wingo <=