Re: GNU Libtool 1.5.8 released.
On Aug 11, 2004, Daniel Reed [EMAIL PROTECTED] wrote: On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) ) Daniel Reed wrote: ) ) libtool-1.4.2-multilib.patch ) )This patch is needed for multilib support. It has been sent upstream ) )but basically rejected in its current form as being too Red Hat specific. ) ) [Is this still the case? Is there an alternate solution for this problem, or ) ) is .multilib still the only one?] ) Thanks for the url. I have to agree with Scott, looks like adding this patch ) here would be a bad thing, it may break other linux distros. Someone, ) someday, will come up with a generic way of doing this that works on all ) flavours of GNU/linux. They don't seem to have done so yet. Would it be reasonable to make this a ./configure option at libtool build time? God, no! It means every package would have to use this option at configure time, otherwise it wouldn't work. I think the best we can do is to run something like: case `$CC $CFLAGS -print-file-name=libc.so || gcc -print-file-name=libc.a` in # common case, good */lib/libc.so | */lib/libc.a) libsuff= ;; # many 64/32 arches use lib for 32-bit libs and lib64 for 64-bit libs */lib64/libc.so | */lib64/libc.a) libsuff=64 ;; # mips64-linux uses lib32 for N32 */lib32/libc.so | */lib32/libc.a) libsuff=32 ;; # Shouldn't happen... What now? *) libsuff= ;; esac This should probably be amended to match Debian GNU/Linux x86_64 practice. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
In regard to: Re: GNU Libtool 1.5.8 released., Bob Friesenhahn said (at...:
When building a multilibed library, a variant of the library could be
built for every possible architectural option, or a subset of the
libraries could be built. It seems to me that being able to choose
from a subset of possible library build options is valuable since
many build options may offer no value to the user. I am not sure
how options would be presented to the installer of
the package, but it should be as easy as possible to select which
variants are build, and it should even be possible for the person
who installs the library to define custom multilib variants to
satisfy local requirements.
I've always envisioned that it would work very similarly to
--{enable,disable}-{shared,static} -- a package that uses libtool
gets a bunch of new configure options for free. What those
options should be is less clear, especially since there will be
differences in what's available for different platforms and OSes.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Hi Bob, Joe, libtoolers: Bob Friesenhahn wrote: It seems that the only valid test to determine the default output architecture is to compile code and then use 'file' or some other utility to determine the architecture. In order to produce multilib output, libtool would need to know the specific options necessary to obtain each desired variant. These options are compiler and linker specific. I agree. Much like the options to produce shared libraries at all involves compiler and linker specific options :-) This is libtool's raison d'etre, and we should aim to have support for multilib in our roadmap. It has been in our TODO file for as long as I've been involved with libtool (pushing 7 years now). Joe Orton wrote: On Fri, Aug 13, 2004 at 03:57:59AM +0200, Ralf Corsepius wrote: Solaris-gcc applies traditional multilibs, i.e. it is using multilib subdirs (A subdir of PREFIX/lib). There is precedent for doing it both ways: IRIX 6.2 and later have /usr/lib, /usr/lib32 and /usr/lib64 for the three supported ABIs (O32, N32 and N64 respectively). How do other Linux vendors (Debian, SuSE etc.) handle this issue? I would expect them to be facing the same problems as RH and to have similar work-arounds applied to libtool. SuSE also ship biarch systems with separate 64-bit /usr/lib64 and 32-bit /usr/lib, I believe Mandrake do too, and I believe Debian haven't worked out how (or whether) to do biarch yet. It seems like we can break the back of the problem with support for the two common multilib approaches described here. I also think that by putting early support in libtool before too many ad-hoc solutions develop (particularly from various GNU/Linux vendors) we are probably well placed to help develop some standardisation before we end up having to support the fragmentation that may eventually arise if we waitp However, it is definitely not a 1.5.x issue, and I don't want to delay 2.0 any further. I think we should revisit the issue once the dust has settled on the 2.0 tree, and we start working on features again. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 2004-08-13 at 05:37, Daniel Reed wrote: ) On Fri, 13 Aug 2004, Ralf Corsepius wrote: ) However, you can not identify the multilib-variant and the multilib ) subdir being used from $host, because it is chosen depending upon the ) flags being passed to gcc: ) sparc-sun-solaris2.8-gcc .. - . (sparcv7) ) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 In the scheme we use, $host would be sparc64-sun-solaris2.8 . AFAIU, all'd you do here, is to invent a convention to be able to apply a similar hack to libtool addressing sparc-sun-solaris as the RH patch does. This does not solve the troubles libtool is facing with multilibs in general. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Daniel Reed wrote: On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) ) Daniel Reed wrote: ) ) libtool-1.4.2-multilib.patch ) )This patch is needed for multilib support. It has been sent upstream ) )but basically rejected in its current form as being too Red Hat specific. ) ) [Is this still the case? Is there an alternate solution for this problem, or ) ) is .multilib still the only one?] ) Thanks for the url. I have to agree with Scott, looks like adding this patch ) here would be a bad thing, it may break other linux distros. Someone, ) someday, will come up with a generic way of doing this that works on all ) flavours of GNU/linux. They don't seem to have done so yet. Would it be reasonable to make this a ./configure option at libtool build time? Something like --enable-redhat-multilib or --with-multilib-flavor=RedHat ? Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Different linux distro's seem to be going with different places to put their 64 bit libs? Do all of them stay consistent? e.g. RedHat is /lib64 /usr/lib64 etc... Debian is usr/x86_64-linux/lib ? and so on. etc. etc. What else is there? Did everyone chose a different system? That'd totally suck :( I know bugger all about this, but I assume that there is a libc in one of these directories on all linux flavours? Can we test for libc.so in various dirs and then work out the proper sys_lib_search_path_spec etc? Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
In regard to: Re: GNU Libtool 1.5.8 released., Peter O'Gorman said (at...: Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Thu, 12 Aug 2004, Tim Mooney wrote: In regard to: Re: GNU Libtool 1.5.8 released., Peter O'Gorman said (at...: Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? Well, lets think a bit. We want to add the 64bit specific directories for linux. Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Seems like it to me. For example, Solaris puts 64-bit libraries in a 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries built for older SPARC processor types. Libraries optimized for 32-bit Ultrasparc are put in the traditional location. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Bob Friesenhahn wrote: On Thu, 12 Aug 2004, Tim Mooney wrote: Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Seems like it to me. For example, Solaris puts 64-bit libraries in a 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries built for older SPARC processor types. Libraries optimized for 32-bit Ultrasparc are put in the traditional location. Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, but linux will have the same $host regardless of being debian, redhat, suse, etc... So the need here, specifically is to identify the directories used by various linux distributions, so that adding something which satisfies RedHat (in this case), does not break debian. Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 13 Aug 2004, Peter O'Gorman wrote: Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, but linux will have the same $host regardless of being debian, redhat, suse, etc... So the need here, specifically is to identify the directories used by various linux distributions, so that adding something which satisfies RedHat (in this case), does not break debian. In other words, the Linux folks should put their heads together and agree on a standard way of doing things, right? :-) I agree that the proprietary Unix vendors are much easier to deal with and that OS identification/version tests should be sufficient in many cases. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-11T20:43-0400, Daniel Reed wrote: ) ) ) libtool-1.4.2-multilib.patch ) Would it be reasonable to make this a ./configure option at libtool build ) time? Actually, it wouldn't. :) The actual problem is that software packaged with stock Libtool does not build properly in our multilib build roots. Right now, we have to manually re-bootstrap several of our packages to use our modified libtool.m4. My goal is to allow us to stop doing that :) (I would like to be able to remove the autotools from our build roots altogether.) So, instead of a libtool-compile-time option, would it be reasonable to a) use an environment variable to set this behavior, or b) have Libtool add an option to libtoolized ./configure scripts, or something else? -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ There go my people. I must find out where they are going so I can lead them. -- Alexandre Ledru-Rollin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Thu, 2004-08-12 at 18:12, Peter O'Gorman wrote: Bob Friesenhahn wrote: On Thu, 12 Aug 2004, Tim Mooney wrote: Why just Linux? Isn't this essentially the same issue that the multi-ABI commercial UNIXes have? Seems like it to me. I am not sure. Solaris-gcc applies traditional multilibs, i.e. it is using multilib subdirs (A subdir of PREFIX/lib). I don't know how multiarchs are implemented in RH's ix86_64 gcc. /usr/lib64 is not a subdir of PREFIX/lib For example, Solaris puts 64-bit libraries in a 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries built for older SPARC processor types. Libraries optimized for 32-bit Ultrasparc are put in the traditional location. Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version as part of $host (solaris2.8). However, you can not identify the multilib-variant and the multilib subdir being used from $host, because it is chosen depending upon the flags being passed to gcc: sparc-sun-solaris2.8-gcc .. - . (sparcv7) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 = There is no fixed host to multilib subdir mapping. IMO, RH's multilib-patch is just a band-aid (read: hack) to help them keep libtool going on their systems, but is not a generalizable approach. How do other Linux vendors (Debian, SuSE etc.) handle this issue? I would expect them to be facing the same problems as RH and to have similar work-arounds applied to libtool. Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Fri, 13 Aug 2004, Ralf Corsepius wrote: Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version as part of $host (solaris2.8). However, you can not identify the multilib-variant and the multilib subdir being used from $host, because it is chosen depending upon the flags being passed to gcc: sparc-sun-solaris2.8-gcc .. - . (sparcv7) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 If I wrap gcc up in a script which provides secret -m options, then you can't see what I am doing. Neener, neener, neener! :-) It seems that the only valid test to determine the default output architecture is to compile code and then use 'file' or some other utility to determine the architecture. In order to produce multilib output, libtool would need to know the specific options necessary to obtain each desired variant. These options are compiler and linker specific. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
) On Fri, 13 Aug 2004, Ralf Corsepius wrote: ) However, you can not identify the multilib-variant and the multilib ) subdir being used from $host, because it is chosen depending upon the ) flags being passed to gcc: ) sparc-sun-solaris2.8-gcc .. - . (sparcv7) ) sparc-sun-solaris2.8-gcc -m64 .. - sparcv9 In the scheme we use, $host would be sparc64-sun-solaris2.8 . -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Wed, Aug 11, 2004 at 02:27:00AM +0900, Peter O'Gorman wrote: Bob Friesenhahn wrote: It has been reported a number of times, and I believe I expressed on the list that this was the single most significant bug related to libtool 1.5. This should fix it. Please confirm. As I understood it the only fix is to not use AC_PROG_CXX at all (i.e. require AC_LIBTOOL_TAGS), since that macro always sets CXX = g++ in the case where it can't find a C++ compiler. So with your patch, I still get the same failure: ... checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. (with a change added the echo inside the if branch) ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) libtool-1.4.2-multilib.patch )This patch is needed for multilib support. It has been sent upstream )but basically rejected in its current form as being too Red Hat specific. ) [Is this still the case? Is there an alternate solution for this problem, or ) is .multilib still the only one?] ) Do you have a url for the thread? The original post is: http://lists.gnu.org/archive/html/libtool-patches/2004-02/msg00050.html Therefore I don't think we can accept this into Libtool in its current form. is: http://lists.gnu.org/archive/html/libtool-patches/2004-03/msg00033.html ) libtool-1.4.2-demo.patch (on x86_64 s390 s390x) )Yes, this is just to disable several nopic tests: afaicr nopic is )meaningless on those archs bicbw... ie a patch should really go upstream )to skip those tests on those archs I guess. ) Well, if you can be bothered to make a real patch, we might look at it. A ) patch that simply removes tests from the Makefile.am is not a good thing[tm] :). Would it be better to keep the test from running with an Automake conditional, or disable it in the test script itself? (I see tests being controlled both ways in Libtool.) tests/demo-nopic.test already skips itself if `config.guess` begins with hppa; should I just extend that check to skip x86_64 and s390? ) libtool-1.5-testfailure.patch )This was contributed by Owen: would probably be worth trying to )push it upstream - though I'm not entirely clear why/if it is needed. ) I can not understand the point of this one. Perhaps Owen can explain why it ) is needed. This was to address a warning generated by Automake. The affected files were being built to be included in both an ar library and a libtool library. demo/Makefile.am: 9: libhello_la_SOURCES = hello.c foo.c 125: libhell0_a_SOURCES = hello.c foo.c pdemo/Makefile.am: 9: libhello_la_SOURCES = longer_file_name_hello.c longer_file_name_foo.c longer_file_name_foo2.c 125: libhell0_a_SOURCES = longer_file_name_hello.c longer_file_name_foo.c Owen's patch duplicates hello.c to hell0.c and makes libhell0_a_SOURCES use that instead of hello.c, etc. The way I work around this in naim is to add an empty _CFLAGS for the libtool target (I believe this workaround was proposed on this list). Which would be more acceptable? Thanks for looking into this! -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ A man that is truly great is he who makes the world his debtor. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-12T00:30+0900, Peter O'Gorman wrote: ) ) libtool-1.4-nonneg.patch ) ) ) libtool-1.5-libtool.m4-x86_64.patch ) ) This too. ) Aw, with changelog entries and stuff :) The entry for libtool-1.4-nonneg.patch in the RPM changelog is: * Thu Jul 13 2000 Elliot Lee [EMAIL PROTECTED] - Fix recognition of ^0[0-9]+$ as a non-negative integer. libtool-1.5-libtool.m4-x86_64.patch, which was originally libtool-1.4.2-s390_x86_64.patch, does not have its own changelog entry. It adds the prefix x86_64 to the list of CPU types that have lt_cv_deplibs_check_method set to pass_all (libtool.m4:2212 in CVS). This may just be my inexperience with Libtool's code, but it appears that section is [now?] always setting lt_cv_deplibs_check_method to pass_all: | # This must be Linux ELF. | linux*) | case $host_cpu in | alpha*|hppa*|i*86|ia64*|m68*|mips*|powerpc*|sparc*|s390*|sh*) | lt_cv_deplibs_check_method=pass_all ;; | *) | # glibc up to 2.1.1 does not perform some relocations on ARM | # this will be overridden with pass_all, but let us keep it just in case | lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )' ;; | esac | lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so` | lt_cv_deplibs_check_method=pass_all | ;; If $host_os begins with linux, and if $host_cpu begins with ..., set lt_cv_deplibs_check_method to pass_all; otherwise, set lt_cv_deplibs_check_method to something else; and record the output of echo /lib/libc.so* /lib/libc-*.so; and set lt_cv_deplibs_check_method to pass_all. Is `echo /lib/libc.so* /lib/libc-*.so` affected by the value of lt_cv_deplibs_check_method, or can the internal case $host_cpu be removed entirely? -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ Desktop and Cygwin ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Daniel Reed wrote: On 2004-08-12T00:30+0900, Peter O'Gorman wrote: ) ) libtool-1.4-nonneg.patch ) ) ) libtool-1.5-libtool.m4-x86_64.patch ) ) This too. ) Aw, with changelog entries and stuff :) The entry for libtool-1.4-nonneg.patch in the RPM changelog is: * Thu Jul 13 2000 Elliot Lee [EMAIL PROTECTED] - Fix recognition of ^0[0-9]+$ as a non-negative integer. After I went to bed, I realized that this patch was not correct. It allows non-numeric strings in the version info, as long as the first digit is numeric. However the current code is only checking for 3 digits or less, so perhaps we simply need to change it to something like: case $current in *[!0-9]*) $echo $modename: CURRENT \`$current' is not a nonnegative integer 12 $echo $modename: \`$vinfo' is not valid version information 12 ;; esac etc... ? This may just be my inexperience with Libtool's code, but it appears that section is [now?] always setting lt_cv_deplibs_check_method to pass_all: Looks like this should just be: linux*) lt_cv_deplibs_check_method=pass_all ;; As you say. It is simply confusing to have stuff override stuff in there. It is in HEAD as well as branch-1-5. I'll remove it after work. Thanks, Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) ) Daniel Reed wrote: ) ) libtool-1.4.2-multilib.patch ) )This patch is needed for multilib support. It has been sent upstream ) )but basically rejected in its current form as being too Red Hat specific. ) ) [Is this still the case? Is there an alternate solution for this problem, or ) ) is .multilib still the only one?] ) Thanks for the url. I have to agree with Scott, looks like adding this patch ) here would be a bad thing, it may break other linux distros. Someone, ) someday, will come up with a generic way of doing this that works on all ) flavours of GNU/linux. They don't seem to have done so yet. Would it be reasonable to make this a ./configure option at libtool build time? Something like --enable-redhat-multilib or --with-multilib-flavor=RedHat ? Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ? -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ True nobility lies not in being superior to another man, but in being superior to one's previous self. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Sat, Aug 07, 2004 at 11:11:14PM +0900, Peter O'Gorman wrote: The Libtool Team is pleased to announce the release of GNU Libtool 1.5.8. It's really great to see regular libtool releases these days! Thanks. Is there any chance of getting a libtool 1.5 release including support for the AC_LIBTOOL_TAGS macro? I keep having to recommend that people stick with libtool 1.4 for generating configure scripts. If AC_LIBTOOL_TAGS was added to 1.5 this could be avoided. Regards, joe ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Joe Orton wrote: Is there any chance of getting a libtool 1.5 release including support for the AC_LIBTOOL_TAGS macro? I keep having to recommend that people stick with libtool 1.4 for generating configure scripts. If I recall correctly, it was decided that it was more a new feature than a bugfix. Also with libtool-2.0 coming real soon now (and libtool-2.0 has such a feature already), it seems unlikely that there will be any further releases from branch-1-5. If there is to be one, we can discuss this at that time. Now, even though configure takes a fair bit longer, there are (as far as I know) fewer bugs in 1.5.8 than there were in 1.4.x, so I am disappointed that you see fit to recommend the older libtool. Maybe you can ensure that the rpm from redhat has this patch and then you can simply recommend that everyone use redhat :-). Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Wed, Aug 11, 2004 at 12:13:44AM +0900, Peter O'Gorman wrote: Joe Orton wrote: Is there any chance of getting a libtool 1.5 release including support for the AC_LIBTOOL_TAGS macro? I keep having to recommend that people stick with libtool 1.4 for generating configure scripts. If I recall correctly, it was decided that it was more a new feature than a bugfix. Also with libtool-2.0 coming real soon now (and libtool-2.0 has such a feature already), it seems unlikely that there will be any further releases from branch-1-5. If there is to be one, we can discuss this at that time. Now, even though configure takes a fair bit longer, there are (as far as I know) fewer bugs in 1.5.8 than there were in 1.4.x, so I am disappointed that you see fit to recommend the older libtool. It always disappoints me to do so too, that's why I'm making this plea :) The fact that libtool 1.5-based configure scripts fail on systems without a C++ compiler is a severe regression which outweighs all the great features and fixes since 1.4, unfortunately. Maybe you can ensure that the rpm from redhat has this patch and then you can simply recommend that everyone use redhat :-). A behaviour and interface change like this isn't something I'd like to advise our libtool maintainer to patch in. Making libtool have different behaviour in different distributions and vs upstream is a cause of great headaches for project maintainers. joe ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Joe Orton wrote: It always disappoints me to do so too, that's why I'm making this plea :) The fact that libtool 1.5-based configure scripts fail on systems without a C++ compiler is a severe regression which outweighs all the great features and fixes since 1.4, unfortunately. I guess I must have seen this report at some point, but I don't remember having done so :( Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
(Hiya. I have recently become Red Hat's libtool package maintainer.) On 2004-08-11T00:32+0900, Peter O'Gorman wrote: ) Joe Orton wrote: ) It always disappoints me to do so too, that's why I'm making this plea ) :) The fact that libtool 1.5-based configure scripts fail on systems ) without a C++ compiler is a severe regression which outweighs all the ) great features and fixes since 1.4, unfortunately. ) I guess I must have seen this report at some point, but I don't remember ) having done so :( I have reported it at least twice, with several months in between. It had been reported numerous times by others and has been reported numerous times since :/ For my own projects, I patch the affected routines via acinclude.m4 to noop the C++ checks. The patch I use was originally posted here, probably over a year ago (it guts an M4 macro). However, I am hesitant to make such a change to Red Hat's shipped version of libtool. For one, the patch I am using disables C++ support entirely (my affected projects are just C). Most importantly, though, this is an actual [and serious] flaw in the autotools, and should be addressed in the upstream, canonical versions. On a related note, the libtool I inherited already has 5 patches applied to it. I would like to eventually ship a clean libtool, and would love to hear back on what the status of these patches are. From the previous maintainer: libtool-1.4-nonneg.patch Afaik this patch is not strictly necessary, but doesn't do any harm either. [it changes some shell script in libtool to detect non-negative numbers better] libtool-1.5-libtool.m4-x86_64.patch I guess this should go upstream if it is not in cvs stable branch already. It trivial but obviously needed to support hammer/ia32e. libtool-1.4.2-multilib.patch This patch is needed for multilib support. It has been sent upstream but basically rejected in its current form as being too Red Hat specific. [Is this still the case? Is there an alternate solution for this problem, or is .multilib still the only one?] libtool-1.4.2-demo.patch (on x86_64 s390 s390x) Yes, this is just to disable several nopic tests: afaicr nopic is meaningless on those archs bicbw... ie a patch should really go upstream to skip those tests on those archs I guess. libtool-1.5-testfailure.patch This was contributed by Owen: would probably be worth trying to push it upstream - though I'm not entirely clear why/if it is needed. I can post these to libtool-patches if the names are unfamiliar to anyone :) -- Daniel Reed [EMAIL PROTECTED] http://people.redhat.com/djr/ http://naim.n.ml.org/ Never be afraid to try something new. Remember: Amateurs built the ark. Professionals built the Titanic. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Bob Friesenhahn wrote:
On Wed, 11 Aug 2004, Peter O'Gorman wrote:
Joe Orton wrote:
It always disappoints me to do so too, that's why I'm making this
plea :) The fact that libtool 1.5-based configure scripts fail on
systems
without a C++ compiler is a severe regression which outweighs all the
great features and fixes since 1.4, unfortunately.
I guess I must have seen this report at some point, but I don't
remember having done so :(
It has been reported a number of times, and I believe I expressed on the
list that this was the single most significant bug related to libtool 1.5.
This should fix it. Please confirm.
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.46
diff -u -3 -p -u -r1.314.2.46 libtool.m4
--- libtool.m4 4 Aug 2004 14:12:05 - 1.314.2.46
+++ libtool.m4 10 Aug 2004 17:24:45 -
@@ -2432,10 +2432,18 @@ AC_DEFUN([AC_LIBTOOL_CXX],
# ---
AC_DEFUN([_LT_AC_LANG_CXX],
[AC_REQUIRE([AC_PROG_CXX])
-AC_REQUIRE([AC_PROG_CXXCPP])
+AC_REQUIRE([_LT_AC_PROG_CXXCPP])
_LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}CXX])
])# _LT_AC_LANG_CXX
+# _LT_AC_PROG_CXXCPP
+# ---
+AC_DEFUN([_LT_AC_PROG_CXXCPP],
+[
+if test -n $CXX test X$CXX != Xno; then
+ AC_PROG_CXXCPP
+fi
+])# _LT_AC_PROG_CXXCPP
# AC_LIBTOOL_F77
# --
@@ -2600,7 +2608,7 @@ AC_DEFUN([AC_LIBTOOL_LANG_CXX_CONFIG], [
AC_DEFUN([_LT_AC_LANG_CXX_CONFIG],
[AC_LANG_PUSH(C++)
AC_REQUIRE([AC_PROG_CXX])
-AC_REQUIRE([AC_PROG_CXXCPP])
+AC_REQUIRE([_LT_AC_PROG_CXXCPP])
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
_LT_AC_TAGVAR(allow_undefined_flag, $1)=
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Daniel Reed wrote: (Hiya. I have recently become Red Hat's libtool package maintainer.) Hi Daniel, On 2004-08-11T00:32+0900, Peter O'Gorman wrote: ) Joe Orton wrote: ) It always disappoints me to do so too, that's why I'm making this plea ) :) The fact that libtool 1.5-based configure scripts fail on systems ) without a C++ compiler is a severe regression which outweighs all the ) great features and fixes since 1.4, unfortunately. ) I guess I must have seen this report at some point, but I don't remember ) having done so :( I have reported it at least twice, with several months in between. It had been reported numerous times by others and has been reported numerous times since :/ I've already apologized and posted a patch asking for confirmation that it works to this list (sorry, should have posted it to -patches, but it was after 2am). On a related note, the libtool I inherited already has 5 patches applied to it. I would like to eventually ship a clean libtool, and would love to hear back on what the status of these patches are. From the previous maintainer: libtool-1.4-nonneg.patch Afaik this patch is not strictly necessary, but doesn't do any harm either. [it changes some shell script in libtool to detect non-negative numbers better] For some reason currently we check for non-negative 1-3 digit numbers, 4 digits are reported as negative. Whee. Post this to patches and I'll apply it. libtool-1.5-libtool.m4-x86_64.patch I guess this should go upstream if it is not in cvs stable branch already. It trivial but obviously needed to support hammer/ia32e. This too. libtool-1.4.2-multilib.patch This patch is needed for multilib support. It has been sent upstream but basically rejected in its current form as being too Red Hat specific. [Is this still the case? Is there an alternate solution for this problem, or is .multilib still the only one?] Do you have a url for the thread? libtool-1.4.2-demo.patch (on x86_64 s390 s390x) Yes, this is just to disable several nopic tests: afaicr nopic is meaningless on those archs bicbw... ie a patch should really go upstream to skip those tests on those archs I guess. Well, if you can be bothered to make a real patch, we might look at it. A patch that simply removes tests from the Makefile.am is not a good thing[tm] :). libtool-1.5-testfailure.patch This was contributed by Owen: would probably be worth trying to push it upstream - though I'm not entirely clear why/if it is needed. I can not understand the point of this one. Perhaps Owen can explain why it is needed. Peter -- Peter O'Gorman - http://www.pogma.com ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
