From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.bugs Subject: Re: INSTALL matters Date: Sat, 09 May 2009 09:24:45 +0100 Message-ID: <87eiuyznsi.fsf@arudy.ossau.uklinux.net> References: <200805160146.17580.bruno@clisp.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1241857509 11657 80.91.229.12 (9 May 2009 08:25:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 May 2009 08:25:09 +0000 (UTC) Cc: bug-guile@gnu.org To: Bruno Haible Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat May 09 10:25:00 2009 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M2hre-0007cB-Dm for guile-bugs@m.gmane.org; Sat, 09 May 2009 10:24:59 +0200 Original-Received: from localhost ([127.0.0.1]:60836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M2hrd-0006m9-Hw for guile-bugs@m.gmane.org; Sat, 09 May 2009 04:24:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M2hrZ-0006kO-5Y for bug-guile@gnu.org; Sat, 09 May 2009 04:24:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M2hrU-0006io-3x for bug-guile@gnu.org; Sat, 09 May 2009 04:24:52 -0400 Original-Received: from [199.232.76.173] (port=40967 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M2hrT-0006if-TY for bug-guile@gnu.org; Sat, 09 May 2009 04:24:47 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:41556) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M2hrT-0007Nd-OV for bug-guile@gnu.org; Sat, 09 May 2009 04:24:48 -0400 Original-Received: from arudy (host86-145-183-207.range86-145.btcentralplus.com [86.145.183.207]) by mail3.uklinux.net (Postfix) with ESMTP id 001FC1F662A; Sat, 9 May 2009 09:24:45 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 737D838021; Sat, 9 May 2009 09:24:45 +0100 (BST) In-Reply-To: <200805160146.17580.bruno@clisp.org> (Bruno Haible's message of "Fri\, 16 May 2008 01\:46\:17 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:4213 Archived-At: Bruno Haible writes: > Hi, Hi Bruno, I'm trying to win a prize here for most delayed email response :-) Seriously, thanks for raising this. This issue, and the related (in my mind) one about having multiple copies of a library installed in different places, keep cropping up now and then, so it would be great to resolve them. First, a couple of assumptions: as far as I understand, - in general, there is no portable way of telling the compiler and linker to look in one set of prefixes for library A, and in a different set of prefixes for library B specifically, therefore, if you have multiple versions of libraries installed in /usr/lib and /usr/local/lib (or /opt/lib, whatever...), there's no way of reliably getting the /usr/lib version of library A and the /usr/local/lib version of library B - worse (at least with the GNU toolchain), if you have multiple versions of library A in /usr/lib and /usr/local/lib, you can't get a consistent build at all, because gcc prefers /usr/include when looking for headers, but ld and ld.so prefer /usr/local/lib when linking. (Or perhaps the other way round. I haven't rechecked the detail for this email, but I'm sure that they were inconsistent when I last checked.) If those are wrong, my following comments may be wrong too. > I'm trying to install guile-1.8.5 on MacOS X 10.5. I've already installed > gmp-4.2.2 with the same --prefix option as I use for guile, This suggests a possibility, of automatically adding $prefix/include to CPPFLAGS and $prefix/lib to LDFLAGS. But see below. > and the configuration > bails out nevertheless: > > $ ./configure --prefix=$HOME/data/local-macos CPPFLAGS=-Wall > ... > checking for __gmpz_init in -lgmp... no > configure: error: GNU MP not found, see README > > guile's README has two paragraphs about this topic. Both are less than > helpful: > > - The first paragraph says that the installer should consider -I options, > but does not say how to pass them (CFLAGS? wrong! CPPFLAGS!), and moreover > does not even mention that LDFLAGS need to be set as well (for -L and > rpath related options). Completely agree that this is not helpful enough. I'll propose an update once we're agreed on the overall picture. > - The second paragraph recommends to rebuild GCC to match --prefix. This > is just gross. It takes a novice user half a dozen attempts to find out > the right set of configure options for building gcc, and then the build > itself takes 10 hours and requires 500 MB of swap space. The README doesn't recommend this; it says that it is a "convenient" option. In some specific contexts - e.g. an admin setting up a box with all 3rd party software under /opt - I think that this would indeed be a convenient option. I agree, though, that those contexts are unlikely to apply to most people, and the README text should be clearer about that. I'll propose an update. > Can you please add an option --with-gmp-prefix or --with-gmp, with which the > installer can *easily* specify where he has installed GMP? > > Precedents: > - mpfr-2.3.1 has > --with-gmp=DIR GMP install directory > --with-gmp-include=DIR GMP include directory > --with-gmp-lib=DIR GMP lib directory > --with-gmp-build=DIR GMP build directory > - cln-1.2.2 has > --with-gmp[=DIR] use external low-level functions from GNU MP > (installed in prefix DIR) [default=yes]. > > Similarly, can you please add an option --with-readline-prefix or > --with-libreadline-prefix, with which the installer can *easily* specify where > he has installed GNU readline? > > Precedents: > - GNU clisp 2.44.1 has > --with-libreadline-prefix[=DIR] search for libreadline in DIR/include and DIR/lib > --without-libreadline-prefix don't search for libreadline in includedir and libdir > - gnulib has a readline.m4 autoconf macro that provides > --with-libreadline-prefix[=DIR] search for libreadline in DIR/include and DIR/lib > --without-libreadline-prefix don't search for libreadline in includedir and libdir I would prefer to document really clearly how to use CPPFLAGS and LDFLAGS, rather than adding these options. I don't like these options because they seem bogus to me. Providing `--with-libreadline-prefix' makes it sound like the build and runtime will look specifically (and only) in that prefix when building/linking readline, and in the default places for other libraries. And that is not true, because there is no way of doing that. Using CPPFLAGS and LDFLAGS is better, in my view, because it corresponds to what the toolchain can actually do - i.e. search in one global set of places for all headers, and in one global set of places for all libraries. Therefore I would like to document the proper use of CPPFLAGS and LDFLAGS, explain when these are needed, and also explain the problem with having multiple library versions installed. Now coming back to the point above about automatically adding $prefix/include to CPPFLAGS and $prefix/lib to LDFLAGS... It's an interesting idea, but I'm sure that it would cause unwanted build behaviour for some people, and it should be trivial (given proper documentation) for people who _do_ want this to set their CPPFLAGS and LDFLAGS; so on balance I don't think we should do this. > As an installer, I'm not going to spend time trying to see which LDFLAGS I need > to set for a package to recognize the libraries that I have installed. I expect > the package to do this by itself. I don't get this last paragraph. You have to add a path either to --with-xxx-prefix or to CPPFLAGS and LDFLAGS, so what difference does it make? Many thanks again for your input on this. Regards, Neil