libtool 1.4.3 searches /usr/lib before -Ldir
I've asked for help about this problem twice in the last few weeks, without any replies. In the meantime I've done some searching in the libtool list history, and I came across this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04324.html This seems to be exactly the same problem I'm having. Now I'm wondering, has the reason, and possibly a solution for this problem been found in the meantime? Regards, Pieter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.3 searches /usr/lib before -Ldir
In regard to: libtool 1.4.3 searches /usr/lib before -Ldir, Pieter...: I've asked for help about this problem twice in the last few weeks, without any replies. I saw your posts, but don't recall whether this is something you've tried with libtool 1.5.2 or not. Have you? The libtool developers have expressed extreme reluctance to spend much time on code that is an evolutionary dead end. All new work is going into the 1.5.x and later lines of development. In the meantime I've done some searching in the libtool list history, and I came across this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04324.html If you download libtool 1.4.3 and look at ltmain.in, you'll see about a dozen places where newlib_search_path is set to something. In each case, the assignment ends up looking like newlib_search_path=$newlib_search_path something else here If you try systematically changing these to newlib_search_path=something else here $newlib_search_path you should eventually be able to arrive at the combination of settings that are causing the problem for you. My *guess* (and that's all it is) is that it's either the place where it's under a case for `-L', or it's the place where you have newlib_search_path=$newlib_search_path $ladir Do some testing, and report back what you find. Better yet, test with libtool 1.5.2. 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://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.3 searches /usr/lib before -Ldir
Dixit Albert Chin (2003-10-21 10:47): The -L option correctly points to the src/verbiste directory, where the newer library has been compiled. However, libtool generates this g++ command to do the linking: g++ -g -Wall -o french-conjugator french_conjugator-french-conjugator.o french_conjugator-Command.o /usr/lib/libxml2.so -lpthread -lz -lm -L/home/ps/cvswork/verbiste/src/verbiste /usr/lib/libverbiste-0.1.so Does this patch (against 1.5) work for you? http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html It should be trivial to apply the patch to your 1.4.3 version. I've tried libtool 1.5 both with and without this patch, and the problem remains the same. But instead of searching /usr/lib explicitly, it searches /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../.. instead, which is equivalent... I've attached a patch (against 1.5) that works for me. At the following point in ltmain.in, I changed the order of the stuff that gets assigned to newlib_search_path. The new directory is now prepended instead of being appended: prog) if test $pass = conv; then deplibs=$deplib $deplibs continue fi if test $pass = scan; then deplibs=$deplib $deplibs newlib_search_path=`$echo X$deplib | $Xsed -e 's/^-L//'` $newlib_search_path else compile_deplibs=$deplib $compile_deplibs finalize_deplibs=$deplib $finalize_deplibs fi ;; This puts the right directory before /usr/lib instead of after. (I notice that this code segment is the only one in the script that compares $pass with 'scan'.) I don't know if this patch would be appropriate for all users of libtool however... -- Pierre Sarrazin sarrazip at sympatico . ca --- ltmain.in.orig 2003-10-22 01:57:53.0 -0400 +++ ltmain.in 2003-10-22 02:24:08.0 -0400 @@ -1883,7 +1883,7 @@ fi if test $pass = scan; then deplibs=$deplib $deplibs - newlib_search_path=$newlib_search_path `$echo X$deplib | $Xsed -e 's/^-L//'` + newlib_search_path=`$echo X$deplib | $Xsed -e 's/^-L//'` $newlib_search_path else compile_deplibs=$deplib $compile_deplibs finalize_deplibs=$deplib $finalize_deplibs ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.3 searches /usr/lib before -Ldir
On Mon, Oct 20, 2003 at 07:32:21PM -0400, Pierre Sarrazin wrote: I have a C++ package that contains a library and two command-line tools. If I install this package through an RPM (on a RedHat 8.0 system), I endup with the lib*.la and lib*.so files in /usr/lib. I get into trouble when I compile the sources of a newer version of the package, while the older version is still installed. You should use libtool 1.5 if you're using C++. The libtool command that is run by make is the following: /bin/sh ../../libtool --mode=link g++ -g -Wall -o french-conjugator french_conjugator-french-conjugator.o french_conjugator-Command.o -lxml2 -lpthread -lz -lm -L../verbiste -lverbiste-0.1 The -L option correctly points to the src/verbiste directory, where the newer library has been compiled. However, libtool generates this g++ command to do the linking: g++ -g -Wall -o french-conjugator french_conjugator-french-conjugator.o french_conjugator-Command.o /usr/lib/libxml2.so -lpthread -lz -lm -L/home/ps/cvswork/verbiste/src/verbiste /usr/lib/libverbiste-0.1.so Does this patch (against 1.5) work for you? http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html It should be trivial to apply the patch to your 1.4.3 version. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4.3 searches /usr/lib before -Ldir
I'm having a problem related to the path that libtool (1.4.3)
uses to search for libraries.
I have a C++ package that contains a library and two command-line
tools. If I install this package through an RPM (on a RedHat 8.0
system), I endup with the lib*.la and lib*.so files in /usr/lib.
I get into trouble when I compile the sources of a newer version
of the package, while the older version is still installed.
For example, I deploy the newer version in /home/ps/cvswork/verbiste.
The library sources are in src/verbiste, and its .libs subdirectory.
The command-line tool sources are in src/commands. The library is
compiled first, then the command-line tools. The error happens when
trying to link the first of those tools.
The libtool command that is run by make is the following:
/bin/sh ../../libtool --mode=link g++ -g -Wall
-o french-conjugator
french_conjugator-french-conjugator.o french_conjugator-Command.o
-lxml2 -lpthread -lz -lm
-L../verbiste -lverbiste-0.1
The -L option correctly points to the src/verbiste directory, where the
newer library has been compiled. However, libtool generates this g++
command to do the linking:
g++ -g -Wall -o french-conjugator
french_conjugator-french-conjugator.o french_conjugator-Command.o
/usr/lib/libxml2.so -lpthread -lz -lm
-L/home/ps/cvswork/verbiste/src/verbiste
/usr/lib/libverbiste-0.1.so
The `-lverbiste-0.1' has been expanded to `/usr/lib/libverbiste-0.1.so'
because the older version of the library is currently installed as an
RPM under /usr. This causes a linking error because the older library
does not have the functions that are expected by the newer code:
/home/ps/cvswork/verbiste/src/commands/french-conjugator.cpp:110:
undefined reference to
`verbiste::FrenchVerbDictionary::getTenseName(verbiste::Tense)'
I wondered why libtool searched a system directory (/usr/lib) before
the explicitly specified one (../verbiste). I opened ../../libtool
and found this (backslash added by me):
for searchdir in $newlib_search_path $lib_search_path \
$sys_lib_search_path $shlib_search_path; do
# Search the libtool library
lib=$searchdir/lib${name}.la
if test -f $lib; then
found=yes
break
fi
done
By inserting echo statements before this loop, I observed this (long
line cut by me):
newlib_search_path=' /usr/lib /home/ps/cvswork/verbiste/src/verbiste'
lib_search_path='/home/ps/cvswork/verbiste/src/commands
/home/ps/cvswork/verbiste/src/verbiste'
The directory specified with -L was added after /usr/lib.
This explains why libverbiste-0.1.la is found in /usr/lib instead
of where -L specified.
The workaround is to uninstall the older library, or at least to
move away /usr/lib/libverbiste-0.1.la.
Is there a clean way to ask libtool to search a certain directory
before any system directory?
My project is autoconfiscated with autoconf 2.57, automake 1.7.2
and libtool 1.4.3. Also, I use g++ 3.2 on a RedHat 8.0 system.
--
Pierre Sarrazin sarrazip at sympatico dot ca
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
problem to compile libtool 1.4.3 with xlc/AIX
I can't compile libtool 1.4.3 under AIX 4.1.3 I got error messages from the compiler when it compiles ltdl.c the compiler is xlc128 (same as xlc) (C for AIX Compiler). $ echo $CC xlc128 $ echo $LIBS -lc128 $ ./configure tycho:/ptolemea/users/gastin/ftp/libtool-1.4.3 $ make Making all in . CONFIG_FILES=libtoolize CONFIG_HEADERS= /bin/sh ./config.status creating libtoolize chmod +x libtoolize Making all in libltdl /bin/sh ./libtool --mode=compile xlc128 -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include -g -c ltdl.c xlc128 -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include -g -c ltdl.c ltdl.c, line 971.24: 1506-196 (S) Initialization between types void* and int is not allowed. ltdl.c, line 1003.18: 1506-196 (S) Initialization between types void* and int is not allowed. ltdl.c, line 3237.58: 1506-280 (E) Function argument assignment between types void* and int(*)(const char*,void*) is not allowed. ltdl.c, line 3243.58: 1506-280 (E) Function argument assignment between types void* and int(*)(const char*,void*) is not allowed. ltdl.c, line 3247.62: 1506-280 (E) Function argument assignment between types void* and int(*)(const char*,void*) is not allowed. ltdl.c, line 3254.62: 1506-280 (E) Function argument assignment between types void* and int(*)(const char*,void*) is not allowed. ltdl.c, line 3261.62: 1506-280 (E) Function argument assignment between types void* and int(*)(const char*,void*) is not allowed. gnumake: *** [ltdl.lo] Error 1 ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [BUG REPORT] libtool 1.4.3 doesn't find dl library
Sorry, *just* after I sent this mail, flibble said, he used the older GGI version, which has libtool 1.4.0. So if the reported bug below is already fixed in libtool 1.4.3, then please let me know. Hi! A user from the GGI project (http://www.ggi-project.org/) found a bug in libtool 1.4.3, when trying to compile GGI on a MIPS architecture. libtool has a wrong regex causing it to reject the dl library though it is available. The snippet from the IRC log: [15:33] flibble libtool says deplibs_check_method=file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib ) [15:34] flibble file says /lib/libdl-2.2.4.so: ELF 32-bit LSB mips-1 shared object, MIPS R3000_LE [bfd bug], version 1, not stripped [15:34] flibble nearly the same, but enough to reject dl library flibble 'fixed' this bug by changing deplibs_check_method to pass_all. I know, this is not the right fix, but it is a quick fix and works for him. Anyone, who knows the right fix? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool 1.4.3 Released
We're pleased to announce the release of Libtool 1.4.3! This is a patch release, the last one in the 1.4.x series, and is compatable with Autoconf 2.13. You can find the new release here: in tarball, ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.3.tar.gz xdelta, ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.2-1.4.3.tar.xdp.gz and diff formats. ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.2-1.4.3.diff Coming soon to a GNU mirror near you! http://www.gnu.org/order/ftp.html Please report bugs to [EMAIL PROTECTED]. Thanks again to all those who contributed. Robert Boehne ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
| You want autoconf -f then. | -f, --force consider all files obsolete | | We do a ./cvsclean right now for autoconf +2.50 which purges | all generated data. I guess that is basically the same. | | You know, you are typically the kind of people who has valid grieves | against Autoconf, but using things that were never documented. | | You have lost me. Why should autoconf document any valid m4 | command? Because Autoconf is not M4! Because such a large framework must make provisions precisely so that the whole architecture work. Ans esyscmd is teh best example of what cannot be kept. | esyscmd is definitely excluded from our framework. | | Then you need to document that. Neither 2.13's nor 2.54's | autoconf.info says anything to that effect. OK. I agree that | Programming in M4 | * | |Autoconf is written on top of two layers: M4sugar, which provides | convenient macros for pure M4 programming, and M4sh, which provides | macros dedicated to shell script generation. | |As of this version of Autoconf, these two layers are still | experimental, and their interface might change in the future. As a | matter of fact, _anything that is not documented must not be used_. is not clear enough, it seems to refer to M4sugar and M4sh only. And | Changed Macro Writing | - | [...] |If you were doing tricky things with undocumented Autoconf internals | (macros, variables, diversions), check whether you need to change | anything to account for changes that have been made. Perhaps you can | even use an officially supported technique in version 2 instead of | kludging. Or perhaps not. is hidden. | But you kept developping your Autoconf instead of coming and | deciding for a solution. | | I cannot parse that sentence. Sorry :) I mean, when you clear hit a limitation of a tool, contacting the developper of the tools will certainly provide a better solution that doing something on your side. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Thomas E. Dickey [EMAIL PROTECTED] writes: | On Tue, 8 Oct 2002, Lars Hecking wrote: | | Bob Friesenhahn writes: | On 8 Oct 2002, Akim Demaille wrote: | |There is one big question which must be answered first: will it have |to be Autoconf 2.13 compatible? | |I *strongly* suggest that it must not. It should AC_PREREQ 2.54 |immediately. Then, I'm fine with checking the M4 code and making it |up to date. If needed, I'll wrap a 2.55 with whatever is needed to |have Libtool work better with Autoconf. | | I agree. I can't imagine why anyone would want to use an antique | version of Autoconf which dates from 1996. | | Because it works? In any case, it's the respective maintainer's choice. | | Making autoconf incompatible with previous versions of itself while not | upping the major release number at the same time was a pretty bad move IMHO. | | Deliberately introducing design incompatibilities simply encourages people | to use other tools. In my experience almost all problems that occur while moving to autoconf 2.5x are outright bugs in the configure.in/aclocal.m4 scripts. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote: In my experience almost all problems that occur while moving to autoconf 2.5x are outright bugs in the configure.in/aclocal.m4 scripts. We've already discussed this before, and I decided not to rely upon your opinion -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Wed, Oct 09, 2002 at 01:15:07PM +0200, Andreas Schwab wrote: Thomas Dickey [EMAIL PROTECTED] writes: | On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote: | In my experience almost all problems that occur while moving to autoconf | 2.5x are outright bugs in the configure.in/aclocal.m4 scripts. | | We've already discussed this before, and I decided not to rely upon your opinion You are free do so, of course, but then don't complain that the rest of the world is moving forward. or going in circles, or - in this case, a random walk. -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Thomas Dickey [EMAIL PROTECTED] writes: | On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote: | In my experience almost all problems that occur while moving to autoconf | 2.5x are outright bugs in the configure.in/aclocal.m4 scripts. | | We've already discussed this before, and I decided not to rely upon your opinion You are free do so, of course, but then don't complain that the rest of the world is moving forward. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Sascha == Sascha Schumann [EMAIL PROTECTED] writes: Sascha We use it for the PHP project (80k lines configure script), Sascha because 2.5x is 5 to 6 times slower That's because it does provide a better service too :( I have timed a lot of the code, and I can tell that we're hitting a M4 limitation here. Hopefully future version of GNU M4 will help. Sascha and contains a dependency-ignorant cache system. Err. It doesn't compute. What do you mean? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Russ == Russ Allbery [EMAIL PROTECTED] writes: Great thread people! I'm happy to see you're alive :) Russ There were a variety of reasons for breaking backward Russ compatibility, like choosing to clean up quoting, but that's a Russ justification for doing it, not an argument that it didn't Russ happen. It very clearly did happen. Calling the autoconf Russ scripts that worked in autoconf 2.13 but not in 2.5x broken is Russ a deflection that I'd be more sympathetic to if the ways in Russ which they were broken were clearly documented in autoconf Russ 2.13, but they weren't. Which means that the language Russ definition was changed (to something much more precise, mind), Russ not that scripts that followed the previous language definition Russ such as it was were broken. I don't want to dive into this debate, and I think that Russ' summary is very satisfying in that it exposes the point of view of all the parties. Whatever your opinion is, this debate is anyway a total loss of time for all of us (except for having the opportunity of reading the few usual good laughs from TEDdy Bear, the great clown of our mailing lists) since Autoconf will not be more 2.13 compatible in the future. If people consider we deliberatedly broken bugward compatibility, then fine, you're free to be wrong. It's not what happened (and I can tell you that a lot of code would not have been written if that was our intention), but I don't care what people think wrt this now, because... Because today the only reasonable attitude is asking ourselves how can we help people making the move. I worked *immensely* on autoupdate, it took me days to write such a complex tool. I wrote documentation explaining proper Autoconf programming. I added sections to ease the transition. I made public calls for people looking for help. I'm ready to do more, but please, tell me what is needed. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Robert == Robert Boehne [EMAIL PROTECTED] writes: Robert Ok, So a 1.4.3 version is desired, that's established. The Robert million-dollar question is: Does current branch-1-4 Libtool do Robert the trick? Robert If so, then a roll out could be done within the week. I would like to find a tarball somewhere (I'm bing cut from CVS currently), and read the M4 code. I'll subscribe to libtool-patches too. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Paolo Bonzini wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. But it also contains more features. Releasing 1.5 should be done by the maintainers, not by a community process; instead I think that such a process is perfectly valid to review patches and ChangeLogs and put them together. The community are the maintainers, therefore a maintainer has spoken for a minor version increment, rather than a patch release increment. Enough has changed to increment the minor version number. Yes, libtool would-be-1.5 has been used by gcc at least since 3.0, so it should be pretty good, but I think that it is easier (in terms of brainwork, not of needed resources) to do a definitive 1.4.x release. Since I'm one of the community, I suggest the release to be 1.5 and that Akim's suggestion for AC_PREREQ a strong point. Perhaps, both a 1.4.3 and a 1.5 where 1.4.3 does a AC_PREREQ 2.13. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
| Sascha and contains a dependency-ignorant cache system. | | What do you mean? | | Each of PHP's bundled extensions has a config.m4 which can be | maintained separately. Autoconf 2.50 and later insert stale | code into configure, when such a config.m4 file changes. You want autoconf -f then. | These files are sourced using | | esyscmd(./scripts/config-stubs ext) | | The shell script prints out an sinclude() line for each | existing config.m4 in a particular sub-directory (e.g. | ext/mysql, ext/session). Apparently, autoconf/autom4te does | not keep track of the time stamp of each sourced file which | then causes the described issue. You know, you are typically the kind of people who has valid grieves against Autoconf, but using things that were never documented. esyscmd is definitely excluded from our framework. But you kept developping your Autoconf instead of coming and deciding for a solution. | Oh, btw, has autoconf 2.5x stopped to generate empty case..esac | constructs? FreeBSD's /bin/sh bombed out on that, and it | violated POSIX. How do I know? Did you send a bug report? Do you have a test case? And BTW, do PHP's extensions finally produce valid HTML code? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
The community are the maintainers, therefore a maintainer has spoken for a minor version increment, rather than a patch release increment. Do you mean a minor version increment starting from branch-1_4 or from HEAD? Paolo ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Akim Demaille [EMAIL PROTECTED] writes: If people consider we deliberatedly broken bugward compatibility, then fine, you're free to be wrong. It's not what happened (and I can tell you that a lot of code would not have been written if that was our intention), but I don't care what people think wrt this now, because... For what it's worth, I don't think you deliberately broke it, and I'm not arguing intentions at all. I'm just trying to relate how it looks from entirely outside the project, when the only information one has to go on is how Autoconf 2.13 works and how Autoconf 2.54 works. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
From: Sascha Schumann [EMAIL PROTECTED] Date: Wed, 9 Oct 2002 19:49:57 +0200 (CEST) Did you send a bug report? Do you have a test case? I'm sorry, it was noticed by so many people, I supposed it would make its way to you. It's the first I've heard of it. Do you have a URL describing the problem? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
a new-feature release is the same work as a bugfix release? ye kiddin'... Bob Friesenhahn wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. Bob On Tue, 8 Oct 2002, Bonzini wrote: We sorely need a libtool 1.4.3 -- autoconf is consistently being blamed for its brokenness and in general its portability is flaky on some systems (like Darwin). I don't have the time and knowledge to propose myself for libtool maintainership, but I can trust people that do have this knowledge and put together the patched versions from various vendors (including Red Hat, Debian, and Mandrake), and post them to the Autoconf and/or Libtool mailing lists for public scrutiny. If the maintainer (who is it? the GNU machines say it is co-maintained by Alexandre Oliva, Gary V. Vaughan and Robert Boehne) says it's ok, then it will be released as 1.4.3; if it cannot be the `official' libtool 1.4.3, at least there will be a place to download a single amended version and people will stop complaining to the wrong mailing list. To contribute, please send me patches that you are using for libtool 1.4.2 at [EMAIL PROTECTED], CCing [EMAIL PROTECTED] . Paolo Bonzini ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, 8 Oct 2002, Guido Draheim wrote: a new-feature release is the same work as a bugfix release? ye kiddin'... I have been using libtool since the beginning, and every new libtool release has essentially been a bugfix release. Unlike Autoconf and Automake, it is impossible to bring Libtool to a plateau of tranquil completeness since it is by definition highly OS and tool dependent. Libtool has always been behind the curve. Libtool is a real rats-nest of a shell script which could only be corrected by starting from scratch. It is difficult to understand and maintain. So, yes, the so-called new-feature release is the same work as a bugfix release, because both of them are just bugfix releases. One is just more advanced in development than the other. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, Oct 08, 2002 at 11:17:55AM -0500, Bob Friesenhahn wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. I'd like to see 1.4.3. Who else is onboard? What is required to make a release happen? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Libtool 1.4.3
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Albert Chin On Tue, Oct 08, 2002 at 11:17:55AM -0500, Bob Friesenhahn wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. I'd like to see 1.4.3. Who else is onboard? What is required to make a release happen? I'd like to see this as well. Incremental changes tend to be easier to swallow. I also found the CVS libtool was not a simple drop-in replacement for 1.4.2. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, Oct 08, 2002 at 03:38:17PM -0500, Robert Boehne wrote: So a 1.4.3 version is desired, that's established. The million-dollar question is: Does current branch-1-4 Libtool do the trick? If so, then a roll out could be done within the week. I've got some patches I'd like to roll in. I'll submit them tomorrow. How about a test tarball 10/12. That should give others enough time to get in some patches that might be in the queue. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Libtool 1.4.3
On Tue, 8 Oct 2002, Howard Chu wrote: I'd like to see 1.4.3. Who else is onboard? What is required to make a release happen? I'd like to see this as well. Incremental changes tend to be easier to swallow. I also found the CVS libtool was not a simple drop-in replacement for 1.4.2. It seems that a lot of people want to see a 1.4.3. I assume that this is mostly to try to improve the portability of existing packages with the least amount of effort. The situation as I currently see it is: o There is a branch (branch-1-4) that was used to to release libtool 1.4, 1.4.1, and 1.4.2. I assume this is where 1.4.3 would live and be released from. o The current availability of libtool maintainership is limited to the extent that it is difficult to find enough time to maintain even a single line of development. We would need a maintainer available to ram-rod the 1.4.3 release. o The head of the main libtool branch is almost ready to release (libtool 1.5). Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool 1.4.3
We sorely need a libtool 1.4.3 -- autoconf is consistently being blamed for its brokenness and in general its portability is flaky on some systems (like Darwin). I don't have the time and knowledge to propose myself for libtool maintainership, but I can trust people that do have this knowledge and put together the patched versions from various vendors (including Red Hat, Debian, and Mandrake), and post them to the Autoconf and/or Libtool mailing lists for public scrutiny. If the maintainer (who is it? the GNU machines say it is co-maintained by Alexandre Oliva, Gary V. Vaughan and Robert Boehne) says it's ok, then it will be released as 1.4.3; if it cannot be the `official' libtool 1.4.3, at least there will be a place to download a single amended version and people will stop complaining to the wrong mailing list. To contribute, please send me patches that you are using for libtool 1.4.2 at [EMAIL PROTECTED], CCing [EMAIL PROTECTED] . Paolo Bonzini ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On 8 Oct 2002, Akim Demaille wrote: There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? I *strongly* suggest that it must not. It should AC_PREREQ 2.54 immediately. Then, I'm fine with checking the M4 code and making it up to date. If needed, I'll wrap a 2.55 with whatever is needed to have Libtool work better with Autoconf. I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob Wouldn't it be better to get libtool 1.5 out the door? The Bob resources required to achieve a releasable product are similar Bob and CVS libtool already contains most of the fixes that would go Bob into a 1.4.3. There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? I *strongly* suggest that it must not. It should AC_PREREQ 2.54 immediately. Then, I'm fine with checking the M4 code and making it up to date. If needed, I'll wrap a 2.55 with whatever is needed to have Libtool work better with Autoconf. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Bob Friesenhahn writes: On 8 Oct 2002, Akim Demaille wrote: There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? I *strongly* suggest that it must not. It should AC_PREREQ 2.54 immediately. Then, I'm fine with checking the M4 code and making it up to date. If needed, I'll wrap a 2.55 with whatever is needed to have Libtool work better with Autoconf. I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. Because it works? In any case, it's the respective maintainer's choice. Making autoconf incompatible with previous versions of itself while not upping the major release number at the same time was a pretty bad move IMHO. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? We use it for the PHP project (80k lines configure script), because 2.5x is 5 to 6 times slower and contains a dependency-ignorant cache system. So, please don't create incompatibilities, unless you really have to. - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, 8 Oct 2002, Earnie Boyd wrote: FWIR, Akim and other developers tried hard to maintain [back|bug]ward compatibility. But, some of the incompatibility was ill formed autoconf syntax so that incompatibility wasn't maintained and instead a better parser was put into place. not at all Conform, it's the right thing to do. not in your lifetime. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, 8 Oct 2002, Lars Hecking wrote: Bob Friesenhahn writes: On 8 Oct 2002, Akim Demaille wrote: There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? I *strongly* suggest that it must not. It should AC_PREREQ 2.54 immediately. Then, I'm fine with checking the M4 code and making it up to date. If needed, I'll wrap a 2.55 with whatever is needed to have Libtool work better with Autoconf. I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. Because it works? In any case, it's the respective maintainer's choice. Making autoconf incompatible with previous versions of itself while not upping the major release number at the same time was a pretty bad move IMHO. Deliberately introducing design incompatibilities simply encourages people to use other tools. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, 8 Oct 2002, Bob Friesenhahn wrote: On 8 Oct 2002, Akim Demaille wrote: There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? I *strongly* suggest that it must not. It should AC_PREREQ 2.54 immediately. Then, I'm fine with checking the M4 code and making it up to date. If needed, I'll wrap a 2.55 with whatever is needed to have Libtool work better with Autoconf. I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. I can't imagine why anyone would want to use code which changes design between one minor release and the next (but P.T.Barnum probably could answer that). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, 8 Oct 2002, Thomas E. Dickey wrote: I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. Because it works? In any case, it's the respective maintainer's choice. Making autoconf incompatible with previous versions of itself while not upping the major release number at the same time was a pretty bad move IMHO. Deliberately introducing design incompatibilities simply encourages people to use other tools. I developed/maintain the configure script for ImageMagick. While the total lines in the generated configure script is meaningless, it is less than 1/2 of what you report for PHP, and PHP's configure script is 4-8X larger than typical configure scripts for other large packages (e.g. 4X larger than the configure script for OpenSSH). This seems odd to me. Having adopted every new Autoconf which has been released, I can happily say that as long as you avoid using undocumented Autoconf internals, it is not particularly difficult to make the minor modifications required to stay current. I don't believe that the decision by some factions to stick with a particular Autoconf software version for the rest of time should be allowed to hinder the development of Libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Hello, Russ! I'm the one who suggested the version 2.50 when it was discussed whether the next version should be 2.14, 2.15 or 3.0. The reason was because there was some incompatibility, but not significant to justify the major number change. It is possible to write configure.in compatible with 2.13 and 2.5x. Whether is was possible to write a 100% correct configure.in that would work with 2.5x before the 2.50 release is a big question, because the documentation was hard to understand. I think that it was possible, although some understanding of m4 was required in addition to the old Autoconf manual. Plus clean hands, of course, which means doing thing right, and not just adding quotes until it works. Two wrongs a right does not make. I.E.: I believe it wrong for any maintainter to not move forward with the current versions of autotools regardless of the maintainer's reasons for not doing so. That comes across as pretty arrogant. It may be arrogant, sure, but in the case of Autoconf it's indeed time to move forward. autoconf 2.5x was a disaster for some projects. That it was a disaster because autoconf 2.13 was woefully inadequate and therefore they had to do things they shouldn't have to do to accomplish what they needed to accomplish doesn't change the fact that autoconf 2.5x was a disaster and represents a vast amount of work that would have to be done. At least 75% of that is the work that should have been done before, i.e. underquoting. Many projects have other priorities, since after all autoconf 2.13 was working for them. The vast majority of packages using autoconf have not updated to autoconf 2.5x in my experience with compiling software. Mind you, Autoconf-generated scripts are meant to work not just for maintainers. They are meant to work for users. One hour spend by a developer is nothing compared to 1000 users downloading bash just to run that damned configure script and 1 users giving up. New versions of Autoconf are more portable. If libtool 1.4.3 is going to provide compatibility with MacOS (i.e. zsh, if I understand correctly), then it's absolutely reasonable to require the developer to spend some time and make sure that the configure script provides the same level of compatibility. -- Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3 - unsolvable issue
Libtool-ers; I think this issue simply becomes mired by stacking up on either side of a for/against line. Previously, it was mentioned that certain troublesome source trees be used as litmus tests for automake or autoconf changes; the same may hold true now for libtool. Brief summary: if you feel that your configure.ac (or .in) represents a very complete coverage of autoconf macros, or represents a number of things that will become incompatible when moving from 2.13/1.4.2, then offer your project as a test-case for auto tools. An alternative is to make the change and, as is done in many sourcebases, release tool-X.Y.Z-pre releases to confirm that you can run on this new set of macros/rules/environment. If it doesn't work, post the URL of your sourcebase, and maybe someone here will help you modernize/adapt. I SAY AGAIN: you might get help. That sometimes happens in this community. :) We all see the benefit of using new/standard features in the tools which were individual kludges and hacks before; we all realize that -- especially if you have not kept current simply because the older releases have worked for you -- it will be difficult to adapt to a significant change. Perhaps we (automake,autoconf,libtool) need to know what problems you're having with a PRE release before we can really gauge the effort to keep you working with the tools. I strongly recommend looking at a preliminary cut. Call it libtool-1.4.3, and make it a CVS rollup without significant engineering effort. Let's test that, get some feedback, and start to contructively work around these problems. More of us could end up with 12-line configure.ac files. That's my rose-coloured-glasses viewpoint. Yeah, it's gonna hurt. Allan Bob Friesenhahn wrote: On Tue, 8 Oct 2002, Thomas E. Dickey wrote: I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. Because it works? In any case, it's the respective maintainer's choice. Making autoconf incompatible with previous versions of itself while not upping the major release number at the same time was a pretty bad move IMHO. Deliberately introducing design incompatibilities simply encourages people to use other tools. I developed/maintain the configure script for ImageMagick. While the total lines in the generated configure script is meaningless, it is less than 1/2 of what you report for PHP, and PHP's configure script is 4-8X larger than typical configure scripts for other large packages (e.g. 4X larger than the configure script for OpenSSH). This seems odd to me. Having adopted every new Autoconf which has been released, I can happily say that as long as you avoid using undocumented Autoconf internals, it is not particularly difficult to make the minor modifications required to stay current. I don't believe that the decision by some factions to stick with a particular Autoconf software version for the rest of time should be allowed to hinder the development of Libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
I developed/maintain the configure script for ImageMagick. While the total lines in the generated configure script is meaningless, it is less than 1/2 of what you report for PHP, and PHP's configure script is 4-8X larger than typical configure scripts for other large packages (e.g. 4X larger than the configure script for OpenSSH). This seems odd to me. There is lot of redundancy included which might be the reason for the slow down. I have thought about using shell functions instead of expanding m4 macros all the time. That might improve things a bit. Having adopted every new Autoconf which has been released, I can happily say that as long as you avoid using undocumented Autoconf internals, it is not particularly difficult to make the minor modifications required to stay current. PHP's system has been supporting autoconf 2.50 since its inception. 2.5x is a burden on the developer's though who improve the build system. The more time an edit/build cycle takes, the less likely someone will try to make modifications and/or test them properly. I don't believe that the decision by some factions to stick with a particular Autoconf software version for the rest of time should be allowed to hinder the development of Libtool. Well, if it is possible for a complex framework as ours to maintain compatibility, there should be only few reasons why it cannot work for libtool as well. Of course, whoever spends their time on libtool development gets to make the final decision. - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, Oct 08, 2002 at 11:36:40AM -0500, Bob Friesenhahn wrote: On 8 Oct 2002, Akim Demaille wrote: There is one big question which must be answered first: will it have to be Autoconf 2.13 compatible? I *strongly* suggest that it must not. It should AC_PREREQ 2.54 immediately. Then, I'm fine with checking the M4 code and making it up to date. If needed, I'll wrap a 2.55 with whatever is needed to have Libtool work better with Autoconf. I agree. I can't imagine why anyone would want to use an antique version of Autoconf which dates from 1996. me too! :) People who stick to the 2.13 guns can stick to the libtool 1.3.3/whatever guns. I see no reason why *new* code (third-party packages) should require a *new* libtool but an *old* autoconf. And the argument that 2.13 works doesn't fly by me: so does 1.4.2 (or whatever the last libtool with near universal acceptance was). I don't think anyone should create themselves a future maintenance burden for the sake of packages that will respond simply by relying on that maintenance to continue, instead of getting with the 2.5x program. Hey, if they're happy with an antique autoconf, they should be happy with an antique libtool. I don't see many messages along the lines of linux kernel 2.0.30 doesn't support my Gigabit Ethernet card! (Actually, I have 2.0.30 at home, on a 486 with 5MB ram. :) I'll probably be flamed to hell and back now... -- [EMAIL PROTECTED] is probably better to bookmark than any employer-specific email address I may have appearing in the headers. Vanity page: http://www.tsct.co.za/~berndj/ [seems down last few days] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Hello! People who stick to the 2.13 guns can stick to the libtool 1.3.3/whatever guns. I see no reason why *new* code (third-party packages) should require a *new* libtool but an *old* autoconf. And the argument that 2.13 works doesn't fly by me: so does 1.4.2 (or whatever the last libtool with near universal acceptance was). That's right unless somebody demonstrates otherwise. I don't think anyone should create themselves a future maintenance burden for the sake of packages that will respond simply by relying on that maintenance to continue, instead of getting with the 2.5x program. I must disagree here. If we say that laziness (a.k.a. conservatism) is not an excuse for the developers who use Autoconf and don't want to upgrade to 2.5x, then twice as much it's not an excuse for Autoconf developers, i.e. for a dozen of highly skilled programmers.. The legitimate reason to require the latest Autoconf is because it's good for the _end_ users. Another legitimate reason is because new tools are more often used together (rather than e.g. old Autoconf with new Libtool), and therefore they are better tested when used together. There may be technical reasons to require latest Autoconf as well, but they are secondary IMHO. I'll probably be flamed to hell and back now... Not in this list. -- Regards, Pavel Roskin ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
[Cc line trimmed] me too! :) I think we have heard all arguments by now. There is no need to reiterate them. Whatever the outcome of this thread might be -- I hope those who work on libtool will continue to provide a toolkit which is suitable for all of us -- developers and users alike. Thanks - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Ok, So a 1.4.3 version is desired, that's established. The million-dollar question is: Does current branch-1-4 Libtool do the trick? If so, then a roll out could be done within the week. Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne AT gnu DOT org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
