* INSTALL matters @ 2008-05-15 23:46 Bruno Haible 2009-05-09 8:24 ` Neil Jerram 0 siblings, 1 reply; 6+ messages in thread From: Bruno Haible @ 2008-05-15 23:46 UTC (permalink / raw) To: bug-guile Hi, 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, 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). - 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. Less than helpful, really. 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 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. Bruno ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: INSTALL matters 2008-05-15 23:46 INSTALL matters Bruno Haible @ 2009-05-09 8:24 ` Neil Jerram 2009-05-10 18:34 ` Bruno Haible 0 siblings, 1 reply; 6+ messages in thread From: Neil Jerram @ 2009-05-09 8:24 UTC (permalink / raw) To: Bruno Haible; +Cc: bug-guile Bruno Haible <bruno@clisp.org> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: INSTALL matters 2009-05-09 8:24 ` Neil Jerram @ 2009-05-10 18:34 ` Bruno Haible 2009-05-17 17:39 ` Neil Jerram 0 siblings, 1 reply; 6+ messages in thread From: Bruno Haible @ 2009-05-10 18:34 UTC (permalink / raw) To: Neil Jerram; +Cc: bug-guile Hi Neil, Neil Jerram wrote in reply to <http://lists.gnu.org/archive/html/bug-guile/2008-05/msg00012.html>: > This issue, and the related (in > my mind) one about having multiple copies of a library installed in > different places Having multiple copies of a package installed in different places is the most normal thing of the world. That's what --prefix is for. > 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 There is. It consists in passing absolute file names for .h and .a or .so files to the linker. If the input you have is a _set_ of of prefixes, this means you need to search for the library in the same way as the compiler or linker would do, and then pass the absolute file names to the compiler or linker. It is a bit far-fetched, but the mentioned macros in gnulib actually do this. Without extra efforts, however, your statement is correct. > 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 Correct. Even if you pass absolute filenames and '-rpath', on some systems, the information written into the executable by the linker does not contain sufficient information for choosing library A from /usr/lib (and not /usr/local/lib) while at the same time choosing library B from /usr/local/lib (and not /usr/lib). > - 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. This is a problem on some BSD systems, IIRC. Also one specific GCC release had this problem on Linux systems, a couple of years ago, and it was fixed in the next GCC release. So I've come to view this as an inconsistency in the GCC installation. The workaround to this situation is to never use /usr/local, but rather pass a different --prefix always. > > 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. Yes. If I have installed gmp with the same --prefix option, then this is needed and desired. Autoconf does not do it automatically. > > 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. Thanks. > > - 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. We must have different interpretations of the term "convenient" :-) > 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 don't think so. The users of this admin will wonder why their programs behave differently when built with GCC than when built with the vendor's compiler. (The reason would be that GCC links with different versions of thirs-party libraries.) > I would prefer to document really clearly how to use CPPFLAGS and > LDFLAGS, rather than adding these options. That would be fine with me as well. The installer can be expected to look into the README and INSTALL files and apply the instructions found there. > 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 It is correct that the option does not mean "hey configure, please look for libreadline *exactly* here". It means "hey configure, I have installed libreadline here". Yes there are weird cases which cannot be supported, like the case with libraries A and B in both /usr and /usr/local, which you mentioned before. But the majority of the cases is not so weird, and in these cases the --with-...-prefix options are helpful. > 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. I find a configure option better, because when the user installs a package, he's not thinking at the level of linker details, but rather "I have installed gmp here. Now how do I tell mpfr or guile about it?" > 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. Fine with me, if following this documentation yields a working build. > 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. Before I came to use --with-...-prefix options, I used CPPFLAGS and LDFLAGS like you say. And quite often, the build failed because - I had not been aware of all dependencies before building the package, or - I had used LDFLAGS="-L/opt/gnu", rather than LDFLAGS="-L/opt/gnu/lib", (Simple typo/thinko, but frustrating anyway.) - I had used LDFLAGS="-L/opt/gnu/lib" but the build needs the 64-bit libraries so I should have used LDFLAGS="-L/opt/gnu/lib64". The --with-...-prefix options do reduce frustration in these cases. > > 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? The difference that I meant is when I use the same --prefix for a couple of related packages. Suppose my goal is to install 'guile'. I learn that it needs 'gmp', so I download and install that, with the same expected prefix. Then I install guile with the same prefix and it refuses to acknowledge the previously installed packages, that it frustrating. I know that some of these problem come from the fact that GNU does not have a package registry or package dependency tracking tool. That's actually good because it gives much more freedom than 'rpm' or 'dpkg' do. But when a package considers a dependency to be absent when it's actually present where you would expect it, this needs correction IMO. Bruno ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: INSTALL matters 2009-05-10 18:34 ` Bruno Haible @ 2009-05-17 17:39 ` Neil Jerram 2009-05-23 23:04 ` Bruno Haible 0 siblings, 1 reply; 6+ messages in thread From: Neil Jerram @ 2009-05-17 17:39 UTC (permalink / raw) To: Bruno Haible; +Cc: bug-guile Bruno Haible <bruno@clisp.org> writes: > Hi Neil, > > Neil Jerram wrote in reply to > <http://lists.gnu.org/archive/html/bug-guile/2008-05/msg00012.html>: >> This issue, and the related (in >> my mind) one about having multiple copies of a library installed in >> different places > > Having multiple copies of a package installed in different places is > the most normal thing of the world. That's what --prefix is for. OK... >> 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 > > There is. It consists in passing absolute file names for .h and .a or .so > files to the linker. If the input you have is a _set_ of of prefixes, > this means you need to search for the library in the same way as the > compiler or linker would do, and then pass the absolute file names to the > compiler or linker. > > It is a bit far-fetched, but the mentioned macros in gnulib actually do this. Thanks for explaining. I've seen these macros in gnulib now. > Correct. Even if you pass absolute filenames and '-rpath', on some systems, > the information written into the executable by the linker does not contain > sufficient information for choosing library A from /usr/lib (and not > /usr/local/lib) while at the same time choosing library B from /usr/local/lib > (and not /usr/lib). I think you're saying here that the new gnulib macros don't work on all platforms. Is that correct? >> - 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. > > This is a problem on some BSD systems, IIRC. Also one specific GCC release > had this problem on Linux systems, a couple of years ago, and it was fixed > in the next GCC release. So I've come to view this as an inconsistency in > the GCC installation. The workaround to this situation is to never use > /usr/local, but rather pass a different --prefix always. OK, that's good news. After looking at the latest GCC and binutils docs, I agree that this old issue seems to be fixed now. (-I and -L directories are now always searched before the system-standard ones.) >> > 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. > > Yes. If I have installed gmp with the same --prefix option, then this > is needed and desired. Autoconf does not do it automatically. But you are happy for this to require saying `--with-gmp-prefix=/opt' (or whatever) when configuring Guile, right? >> 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 don't think so. The users of this admin will wonder why their programs > behave differently when built with GCC than when built with the vendor's > compiler. (The reason would be that GCC links with different versions of > thirs-party libraries.) In any case, this debate isn't at all Guile-specific; more on that below. >> 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 > > It is correct that the option does not mean "hey configure, please > look for libreadline *exactly* here". It means "hey configure, I have > installed libreadline here". > > Yes there are weird cases which cannot be supported, like the case > with libraries A and B in both /usr and /usr/local, which you mentioned > before. But the majority of the cases is not so weird, and in these > cases the --with-...-prefix options are helpful. Now I'm confused. I thought that doing what the new gnulib macros do (i.e. specifying full paths to the linker, and using rpath) means that cases like these _can_ be supported - at least on the platforms where the full paths are stored and respected. >> 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. > > I find a configure option better, because when the user installs a > package, he's not thinking at the level of linker details, but rather > "I have installed gmp here. Now how do I tell mpfr or guile about it?" OK, I agree now that that makes sense. > Before I came to use --with-...-prefix options, I used CPPFLAGS and > LDFLAGS like you say. And quite often, the build failed because > - I had not been aware of all dependencies before building the package, or > - I had used LDFLAGS="-L/opt/gnu", rather than LDFLAGS="-L/opt/gnu/lib", > (Simple typo/thinko, but frustrating anyway.) > - I had used LDFLAGS="-L/opt/gnu/lib" but the build needs the 64-bit libraries > so I should have used LDFLAGS="-L/opt/gnu/lib64". > > The --with-...-prefix options do reduce frustration in these cases. > >> > 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? > > The difference that I meant is when I use the same --prefix for a couple of > related packages. Suppose my goal is to install 'guile'. I learn that it needs > 'gmp', so I download and install that, with the same expected prefix. Then I > install guile with the same prefix and it refuses to acknowledge the previously > installed packages, that it frustrating. OK, so you _do_ think that $prefix/lib should be added to LDFLAGS by default, and $prefix/include to CPPFLAGS. Is there an autoconf macro to do that? If there is, does it support a ./configure option for disabling it, for any cases where it isn't wanted? Overall, then... 1. I think I agree now that using the gnulib macros to provide --with-xxx-prefix options is a good idea. I'm nervous about adding a build dependency on so much new code (e.g. AC_LIB_LINKFLAGS_BODY is nearly 500 lines long), but I suppose that must be the right thing to do for the GNU project as a whole, and that if there are problems we'll just work through them. 2. There is a lot of subtlety involved in understanding how these options work, and what can be relied on on different platforms, and explaining that to users; and none of that is Guile-specific. So rather than explaining bits of this in Guile's FAQ/web pages/whatever it would be better to point to a reliable place where it's explained more generally. Is there already such a place? If not, any suggestions for where it should be? I'm happy to draft an initial text, if nothing already exists. (Ludovic, do you have a view on all this? Any one else?) Many thanks again for your input on this stuff. Regards, Neil ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: INSTALL matters 2009-05-17 17:39 ` Neil Jerram @ 2009-05-23 23:04 ` Bruno Haible 2009-06-15 19:40 ` Neil Jerram 0 siblings, 1 reply; 6+ messages in thread From: Bruno Haible @ 2009-05-23 23:04 UTC (permalink / raw) To: Neil Jerram; +Cc: bug-guile About the topic how the installing person can tell configure where to find the previously installed gmp, Neil Jerram wrote: > > Even if you pass absolute filenames and '-rpath', on some systems, > > the information written into the executable by the linker does not contain > > sufficient information for choosing library A from /usr/lib (and not > > /usr/local/lib) while at the same time choosing library B from /usr/local/lib > > (and not /usr/lib). > > I think you're saying here that the new gnulib macros don't work on all > platforms. Is that correct? In the weird cases that you are mentioning (like /dir1/lib/ and /dir2/lib/ which each contain libA and libB, and the user asks to use /dir1/lib/libA.so and /dir2/lib/libB.so), yes, there are platforms where this will not work. But these are not the typical cases and not the common cases. In this case, where the emphasis is on making the user's life easier, it is acceptable to choose a solution that "works" only in 98% of the cases. > >> This suggests a possibility, of automatically adding $prefix/include > >> to CPPFLAGS and $prefix/lib to LDFLAGS. > > > > Yes. If I have installed gmp with the same --prefix option, then this > > is needed and desired. Autoconf does not do it automatically. > > But you are happy for this to require saying `--with-gmp-prefix=/opt' > (or whatever) when configuring Guile, right? I'm happy with any solution that minimizes the guesswork that the installing person has to do. > Now I'm confused. I thought that doing what the new gnulib macros do > (i.e. specifying full paths to the linker, and using rpath) means that > cases like these _can_ be supported - at least on the platforms where > the full paths are stored and respected. These platforms are not the majority. The majority of platforms (including glibc systems, Solaris systems) use ELF. ELF shared libraries store their dependencies in the form of a directory path and basenames of libraries. Example: $ readelf -d /packages/gnu/lib/libmpfr.so Dynamic section at offset 0x2e8ac contains 23 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libgmp.so.3] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libmpfr.so.1] 0x0000000f (RPATH) Library rpath: [/packages/gnu/lib] ... When I do $ ldd /packages/gnu/lib/libmpfr.so linux-gate.so.1 => (0xffffe000) libgmp.so.3 => /packages/gnu/lib/libgmp.so.3 (0xf7ee8000) libc.so.6 => /lib/libc.so.6 (0xf7d79000) /lib/ld-linux.so.2 (0xf7f4c000) the absolute filename /packages/gnu/lib/libgmp.so.3 is already the result of the search of the 'NEEDED' file in the 'RPATH'. So, what you view as a problem in the gnulib macros is a system file format limitation. > > The difference that I meant is when I use the same --prefix for a couple of > > related packages. Suppose my goal is to install 'guile'. I learn that it needs > > 'gmp', so I download and install that, with the same expected prefix. Then I > > install guile with the same prefix and it refuses to acknowledge the previously > > installed packages, that it frustrating. > > OK, so you _do_ think that $prefix/lib should be added to LDFLAGS by > default, and $prefix/include to CPPFLAGS. Yes. This makes most sense for the installing user. > Is there an autoconf macro > to do that? If there is, does it support a ./configure option for > disabling it, for any cases where it isn't wanted? Good points :-) You are welcome to ask for this on the autoconf list; I support your idea. > Overall, then... > > 1. I think I agree now that using the gnulib macros to provide > --with-xxx-prefix options is a good idea. I'm nervous about adding a > build dependency on so much new code (e.g. AC_LIB_LINKFLAGS_BODY is > nearly 500 lines long), but I suppose that must be the right thing to > do for the GNU project as a whole, and that if there are problems > we'll just work through them. The AC_LIB_LINKFLAGS_BODY is maintained for a couple of years already. Most problems must have been shaken out already: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/lib-link.m4;h=21442033c87bd65912d4337d2f3fe686da708e01;hb=68dfc9591e97db34b5ba693da028ff1f356a12b7 > 2. There is a lot of subtlety involved in understanding how these > options work, and what can be relied on on different platforms, and > explaining that to users; and none of that is Guile-specific. So > rather than explaining bits of this in Guile's FAQ/web pages/whatever > it would be better to point to a reliable place where it's explained > more generally. Is there already such a place? If not, any > suggestions for where it should be? I'm happy to draft an initial > text, if nothing already exists. The doc is also in gnulib, at http://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html (generated from gnulib/doc/havelib.texi). It's explained in some detail, but more from the perspective of the developer than from the view of the user. Bruno ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: INSTALL matters 2009-05-23 23:04 ` Bruno Haible @ 2009-06-15 19:40 ` Neil Jerram 0 siblings, 0 replies; 6+ messages in thread From: Neil Jerram @ 2009-06-15 19:40 UTC (permalink / raw) To: Bruno Haible; +Cc: bug-guile Bruno Haible <bruno@clisp.org> writes: > In the weird cases that you are mentioning (like /dir1/lib/ and /dir2/lib/ > which each contain libA and libB, and the user asks to use /dir1/lib/libA.so > and /dir2/lib/libB.so), yes, there are platforms where this will not work. > > But these are not the typical cases and not the common cases. In this case, > where the emphasis is on making the user's life easier, it is acceptable to > choose a solution that "works" only in 98% of the cases. I agree; I just wanted to make sure that I fully understood. >> OK, so you _do_ think that $prefix/lib should be added to LDFLAGS by >> default, and $prefix/include to CPPFLAGS. > > Yes. This makes most sense for the installing user. And I see now that havelib does this. >> Is there an autoconf macro >> to do that? If there is, does it support a ./configure option for >> disabling it, for any cases where it isn't wanted? > > Good points :-) You are welcome to ask for this on the autoconf list; I > support your idea. OK, but I'll wait for a case (if any) where it's needed. > The AC_LIB_LINKFLAGS_BODY is maintained for a couple of years already. > Most problems must have been shaken out already: > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/lib-link.m4;h=21442033c87bd65912d4337d2f3fe686da708e01;hb=68dfc9591e97db34b5ba693da028ff1f356a12b7 [...] > The doc is also in gnulib, at > http://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html > (generated from gnulib/doc/havelib.texi). It's explained in some > detail, but more from the perspective of the developer than from the > view of the user. Many thanks for all your input on this subject, Bruno. I've applied your suggestions to Guile's master branch (which will become the next stable release series, 2.0.x): http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=39b94fee4304d56babf5bd62e10c5786a79f4389 http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=a89cafc0562942680db63fe8ddf89f466ba2f7af If you have any further comments on this, I'd be happy to hear them. Regards, Neil ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-15 19:40 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-15 23:46 INSTALL matters Bruno Haible 2009-05-09 8:24 ` Neil Jerram 2009-05-10 18:34 ` Bruno Haible 2009-05-17 17:39 ` Neil Jerram 2009-05-23 23:04 ` Bruno Haible 2009-06-15 19:40 ` Neil Jerram
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).