From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Nieuwenhuizen Newsgroups: gmane.lisp.guile.devel 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 Organization: www.AvatarAcademy.nl Message-ID: <1300608500.22746.69.camel@vuurvlieg> References: <1296330082.8111.371.camel@vuurvlieg> <874o8r8kdn.fsf@gnu.org> <1297765259.2325.283.camel@vuurvlieg> <1298540378.4306.71.camel@vuurvlieg> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1300608533 16392 80.91.229.12 (20 Mar 2011 08:08:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 Mar 2011 08:08:53 +0000 (UTC) Cc: Ludovic =?ISO-8859-1?Q?Court=E8s?= , Bruno Haible , Ralf Wildenhues , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 20 09:08:47 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q1Dgs-0006WP-HA for guile-devel@m.gmane.org; Sun, 20 Mar 2011 09:08:46 +0100 Original-Received: from localhost ([127.0.0.1]:54689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1Dgr-0002vz-2w for guile-devel@m.gmane.org; Sun, 20 Mar 2011 04:08:45 -0400 Original-Received: from [140.186.70.92] (port=36430 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1Dgi-0002Wb-NA for guile-devel@gnu.org; Sun, 20 Mar 2011 04:08:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1Dgh-0007Kk-4B for guile-devel@gnu.org; Sun, 20 Mar 2011 04:08:36 -0400 Original-Received: from smtp-vbr19.xs4all.nl ([194.109.24.39]:3011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1Dgg-0007Kb-Nz; Sun, 20 Mar 2011 04:08:35 -0400 Original-Received: from [192.168.1.112] (peder.onsbrabantnet.nl [88.159.206.46] (may be forged)) (authenticated bits=0) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id p2K88KXf046921; Sun, 20 Mar 2011 09:08:21 +0100 (CET) (envelope-from janneke-list@xs4all.nl) In-Reply-To: X-Mailer: Evolution 2.30.3 X-Virus-Scanned: by XS4ALL Virus Scanner X-MIME-Autoconverted: from 8bit to quoted-printable by smtp-vbr19.xs4all.nl id p2K88KXf046921 X-detected-operating-system: by eggs.gnu.org: FreeBSD 4.6-4.9 X-Received-From: 194.109.24.39 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:11923 Archived-At: 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 downloa= d > the tarball, ./configure && make && make install, and voila. You run > Guile and it works. Sweet! >=20 > So now you follow the manual, and it says that you can build your own > Guile via: >=20 > $ gcc -o simple-guile simple-guile.c $(pkg-config guile-2.0 --cflags -= -libs) >=20 > which in your case expands out to >=20 > $ gcc -o simple-guile simple-guile.c -I/usr/local/include/guile/2.0 -L= /usr/local/include -lguile-2.0 >=20 > And it compiles and links. Awesome. >=20 > However when you run the simple-guile it doesn't work: >=20 > $ ./simple-guile > error: could not find libguile-2.0.so >=20 > Why is this? It's because in Fedora, /usr/local/lib is not in the > default runtime library search path. >=20 > If we were compiling on Debian this would work because /usr/local/lib i= s > in the default library search path, though we would see the issue if we > installed to (e.g.) /opt/guile. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > 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 th= e > 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 wan= t > 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=3D..., --with-libBAR-prefix=3D... 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=20 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. --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.= nl =20