[PATCH] Pass -g* through to linker
This is needed for -flto so that debugging information isn't dropped. * ltmain.m4sh (func_mode_link): Pass through -g*. --- build-aux/ltmain.m4sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh index 30f99f4..55f1a0b 100644 --- a/build-aux/ltmain.m4sh +++ b/build-aux/ltmain.m4sh @@ -5090,11 +5090,11 @@ func_mode_link () # @fileGCC response files # -tp=*Portland pgcc target processor selection # --sysroot=* for sysroot support - # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization + # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization # -stdlib=*select c++ std lib with clang -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \ - -O*|-flto*|-fwhopr*|-fuse-linker-plugin|-stdlib=*) + -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-stdlib=*) func_quote_for_eval $arg arg=$func_quote_for_eval_result func_append compile_command $arg -- 1.7.12 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Setting shared lib version not functioning
John Calcote john.calc...@gmail.com writes: One thing that bothers me a little is that we never really did solve Gerald's original problem. He said his library was created just fine when he was passing 2:0:0, but when he switched to 2:0:1, it created a library with a version number of 1:1:0. Now, why would Libtool do this? Granted, he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So why did Libtool convert it to 1:1:0? For the linux way of library versioning the library suffix is computed as (current-age).age.revision, thus 2:0:1 maps to 1.1.0. A libtool version of 1:1:0 whould map to 1.0.1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
bootstrap: CVS is history
The libtool repository no longer uses CVS. Andreas. 2009-02-18 Andreas Schwab sch...@suse.de * bootstrap: Remove references to CVS. diff --git i/bootstrap w/bootstrap index f8b44c1..0b3648f 100755 --- i/bootstrap +++ w/bootstrap @@ -1,7 +1,7 @@ #! /bin/sh -# bootstrap -- Helps bootstrapping libtool, when checked out from CVS. +# bootstrap -- Helps bootstrapping libtool, when checked out from repository. # -# Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc, +# Copyright (C) 2003, 2004, 2005, 2006, 2009 Free Software Foundation, Inc, # Mritten by Gary V. Vaughan, 2003 # # This file is part of GNU Libtool. @@ -47,7 +47,7 @@ export SHELL case $1 in --help|-h*) cat EOF -`echo $0 | sed 's,^.*/,,g'`: This script is designed to bootstrap a fresh CVS checkout +`echo $0 | sed 's,^.*/,,g'`: This script is designed to bootstrap a fresh repository checkout of Libtool. Useful environment variable settings: reconfdirs='. libltdl' Do not bootstrap the old test suite. WORKING_LIBOBJ_SUPPORT=: Declare that you have fixed LIBOBJDIR support @@ -149,7 +149,7 @@ rm -f Makefile # Make a dummy libtoolize script for autoreconf: cat $auxdir/libtoolize 'EOF' #! /bin/sh -# This is a dummy file for bootstrapping CVS libtool. +# This is a dummy file for bootstrapping libtool. echo $0: Bootstrap detected, no files installed. | sed 's,^.*/,,g' exit 0 EOF -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: git history buglet - I'm not the author of /that/...
Ralf Wildenhues ralf.wildenh...@gmx.de writes: Thanks. That would mean we could fix the appearance in the savannah tree, for the web view. Is it possible to move (pull) grafts from one repository to another? No. You have to manually add the grafts to every clone. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: git history buglet - I'm not the author of /that/...
Ralf Wildenhues ralf.wildenh...@gmx.de writes: or we could look into adding a graft that fixes authorship. Haven't done anything like the latter before, but AIUI grafts are the hacks to do things like that. A graft won't help because it only works locally. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool optimization
Bob Friesenhahn [EMAIL PROTECTED] writes: A little time in the profiler will quickly discover where bash is being slow and then someone can re-write that bit of the code to be more efficient. There has not been a release of bash for two years now. Bash 4.0 is in pretest now. This might be the perfect time to do this profiling. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autconf, configure purify...
Ralf Wildenhues [EMAIL PROTECTED] writes: - many vendor shells complain about 'test -z' without further argument: A POSIX-compliant test won't, and returns zero. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Separate CPPFLAGS for static and shared libs
Vikram Ambrose [EMAIL PROTECTED] writes: Andreas Schwab wrote: Vikram Ambrose [EMAIL PROTECTED] writes: Can someone suggest a way I can produce both a static and shared library with libtool/autoconf/automake that are compiled with different CPPFLAGS? You can use #ifdef PIC. Andreas. I looked up fpic and fPIC in the gcc man page. I dont understand how this helps. Could you elaborate? libtool defines it when compiling the pic object. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Jim Meyering [EMAIL PROTECTED] writes: I gave up on git-cvsimport a while ago, since it was so slow compared to parsecvs, but mainly because it would actually *reverse* revisions some time. E.g., it would sometimes put CVS version 1.2 before 1.1. That's a cvsps problem, not specific to git cvsimport. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEADS-UP: git repo issues
Ralf Wildenhues [EMAIL PROTECTED] writes: we messed up with your conversion from CVS to git. More precisely, when we announced that git would be the primary repo, it had - all tags pointing to wrong trees, - no signed tags, - a seemingly bogus history for the tree before version 1.2c. We have fixed the first two issues now, and are ignoring the last. We might look into having the old CVS history available for people who'd like to do archeology. AFAICS the history in the git repository correctly matches the CVS tree, only the tags are pointing to the wrong commits. For you, that means, if you've cloned the git repository before now, you will have to take some steps in order to have the right tags. This is how you delete all local tags and fetch them again from upstream (do not do this if you have added tags yourself locally!): git tag -d `git tag -l` git pull Just running git fetch --tags should be enough. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEADS-UP: git repo issues
Ralf Wildenhues [EMAIL PROTECTED] writes: Hi Andreas, * Andreas Schwab wrote on Sat, Apr 19, 2008 at 11:50:58AM CEST: AFAICS the history in the git repository correctly matches the CVS tree, only the tags are pointing to the wrong commits. Did you check whether the correct commits are even present in the tree? If so, then I suppose we can fix them up manually. The basic problem seems to be that the history of the libtool.prj files is about 18 months younger than the rest of the history, but still tagged with the corresponding release tags. This confuses cvsps, which has associated the tags with the dates corresponding to the libtool.prj history. I think it should be possible to find the correct commits for these tags. Ralf Wildenhues [EMAIL PROTECTED] writes: git tag -d `git tag -l` git pull Just running git fetch --tags should be enough. If you have already fetched the wrong tags before, then that won't overwrite them. Works for me with the default git configuration. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEADS-UP: git repo issues
Ralf Wildenhues [EMAIL PROTECTED] writes: Hi Andreas, * Andreas Schwab wrote on Sat, Apr 19, 2008 at 11:50:58AM CEST: AFAICS the history in the git repository correctly matches the CVS tree, only the tags are pointing to the wrong commits. Did you check whether the correct commits are even present in the tree? Ok, it's much worse than I thought. The early history is pretty much messed up by cvsps, which has the tendency to put revisions in the wrong order when commits with the same commit message are very close to each other. Since almost all of the initial import to CVS was commited with no commit message, there were many opportunities for cvsps to get it wrong, unfortunately. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Ralf Wildenhues [EMAIL PROTECTED] writes: GNU Libtool's primary source repository is now managed with git: http://savannah.gnu.org/git/?group=libtool Note that there were several conversions, so the current repo has been rewound and is not a continuation of the earlier, read-only git repo. There are now many release-* tags that point to the same commit, which is preceded by a series of commits that only change the file libtool.prj (apparently some kind of control file for PRCS). In the CVS repository these tags were all conntected to different changesets. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Ralf Wildenhues [EMAIL PROTECTED] writes: I don't quite understand what happened. With the repo converted from CVS, the tag SHAs were all different, but they already pointed to the same tree object. Did they? Then the CVS import was already broken, since the tags definitely denote different trees in the CVS repo. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Gary V. Vaughan [EMAIL PROTECTED] writes: So my question is how did you find the stale tags? Try browsing with gitk --all. You will soon notice the tags that are heads by itself, instead of marking a commit on the ancestry of an existing head. Also, git merge-base master release-2-2-2 does not even find a common parent. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
Ralf Wildenhues [EMAIL PROTECTED] writes: Hello Eric, Gary, * Gary V. Vaughan wrote on Wed, Apr 16, 2008 at 11:51:48PM CEST: On 16 Apr 2008, at 16:47, Eric Blake wrote: there are now some stale tags in savannah's libtool.git, which point to commits prior to your various git- filter operations (for example, the tag release-2-2-2 http://git.sv.gnu.org/gitweb/?p=libtool.git;a=tag;h=c7bb42 points to http://git.sv.gnu.org/gitweb/? p=libtool.git;a=commit;h=2bbe5d rather than http://git.sv.gnu.org/gitweb/?p=libtool.git;a=commit;h=724f291). Are you planning on rewinding those tags to point to something more appropriate? And if so, please post the new SHA1 of the tags. Yes, I think I should do so. How can I do it? And what's more, what did I forget to do so that this could happen? You probably forgot to explicitly push out the modified tags. Since tags are supposed to be immutable you have to take explicit steps to modify them. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: _lt_libltdl_LTX_preloaded_symbols in consistence.
Ralf Wildenhues [EMAIL PROTECTED] writes: If the package has a custom ./bootstrap or ./autogen.sh, then that is the way to go. I wouldn't count on that. Many packages have a autogen.sh that is far inferior to autoreconf. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: moving to git
Ralf Wildenhues [EMAIL PROTECTED] writes: Now, before we set all things in stone, we'd like to avoid any hard feelings as long as things can still be fixed: The conversion causes, among others, several people to be listed with several email addresses. There is a commit with a strange address: commit 1e0e23c70dbbf7f62bd0a19fdd5730493c08f833 Author: Andreas Schwab [EMAIL PROTECTED] Date: Mon Jul 14 22:51:59 2003 + * libtool.m4 (_LT_AC_LOCK): Also match powerpc64-*linux* in addition to ppc64-*linux*. From Markus Meissner [EMAIL PROTECTED]. Apparently this was extracted from the gnu.org mail archives which mangles text that looks like mail addresses (both should be @suse.de). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ http://lists.gnu.org/mailman/listinfo/libtool
libltdl memory corruption
libltdl uses memory after free when initialized twice.
$ cat ltdl.c
#include ltdl.h
int
main ()
{
lt_dlinit ();
lt_dlexit ();
lt_dlinit ();
lt_dlexit ();
}
$ gcc ltdl.c -o ltdl -lltdl
$ MALLOC_CHECK_=2 ./ltdl
Segmentation fault
The bug is that preopen_LTX_get_vtable returns a pointer to memory that
has already been freed by lt_dlexit.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool
[libtool 2.1b] testsuite: 16 54 55 56 failed
16. convenience.at:69: testing ...
./convenience.at:70: { test -n $CXX test X$CXX != Xno; } || (exit 77)
libtool: compile: g++ -c main1.cpp -o .libs/main1.o
/usr/src/packages/BUILD/libtool-2.1b/libtool: line 821: g++: command not found
libtool: compile: g++ -c a1.cpp -o .libs/a1.o
/usr/src/packages/BUILD/libtool-2.1b/libtool: line 821: g++: command not found
libtool: link: `a1.lo' is not a valid libtool object
libtool: compile: g++ -c main2.cpp -o .libs/main2.o
/usr/src/packages/BUILD/libtool-2.1b/libtool: line 821: g++: command not found
libtool: compile: g++ -c a2.cpp -o .libs/a2.o
/usr/src/packages/BUILD/libtool-2.1b/libtool: line 821: g++: command not found
libtool: link: `a2.lo' is not a valid libtool object
libtool: compile: g++ -c main3.cpp -o .libs/main3.o
/usr/src/packages/BUILD/libtool-2.1b/libtool: line 821: g++: command not found
libtool: compile: g++ -c a3.cpp -o .libs/a3.o
/usr/src/packages/BUILD/libtool-2.1b/libtool: line 821: g++: command not found
libtool: link: `a3.lo' is not a valid libtool object
./convenience.at:91: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o
liba12.la liba1.la liba2.la -rpath /notexist
stderr:
libtool: link: cannot find the library `liba1.la' or unhandled argument
`liba1.la'
stdout:
./convenience.at:91: exit code was 1, expected 0
16. convenience.at:69: 16. C++ convenience archives (convenience.at:69): FAILED
(convenience.at:91)
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.1b] testsuite: 16 54 55 56 failed
Gary V. Vaughan [EMAIL PROTECTED] writes: Do you have a C++ compiler installed? No. What did configure report in the 'checking for g++' test? 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.exe... 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 dependency style of g++... none Did you have CXX set in your environment when you ran configure? No. I cannot answer the other questions ATM, because all I have is the build log. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.1b] testsuite: 16 54 55 56 failed
Bob Friesenhahn [EMAIL PROTECTED] writes: On Fri, 1 Feb 2008, Andreas Schwab wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: Do you have a C++ compiler installed? No. I have a similar situation with Fortran since I have no other use for a Fortran compiler. In order to make the tests happy, I set both F77 and FC to 'no' in my /usr/local/share/config.site file. Presumably you could do the same for CXX. There is no problem with the missing fortran compiler. It looks like an autoconf bug: if no C++ compiler is found it uses g++ regardless. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: FYI: libtool--devo--1.0--patch-195
Peter O'Gorman [EMAIL PROTECTED] writes: Gary V. Vaughan wrote: Gah! I'm lost... These are connected somehow? :-( heheh, Hi Gary, sorry. I'm attempting to remove unneeded loops, in case you hadn't guessed and I noticed this: # The preopen pass in lib mode reverses $deplibs; put it back here # so that -L comes before libs that need it for instance... if test $linkmode,$pass = lib,link; then ## FIXME: Find the place where the list is rebuilt in the wrong ##order, and fix it there properly Every pass basically reverses deplibs, so if you have an uneven number of passes Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
A test that is never true
In ltmain.in around line 1553:
if test $linkmode,$pass = lib,link ||
test $linkmode,$pass = prog,scan ||
{ test $linkmode = oldlib test $linkmode = obj; }; then
$linkmode cannot be both oldlib and obj at the same time.
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
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
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: printing exceptions?
Alexandre Oliva [EMAIL PROTECTED] writes: | However, I kind of fail to see the point of having -lgcc before -lc. The point of having -lgcc before -lc is that -lgcc can add references to -lc functions that were not referenced before. If you have -lgcc only after -lc those references cannot be resolved in a static link. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE GmbH, 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: PATCH: Fix libtool to support Linux/mips
Alexandre Oliva [EMAIL PROTECTED] writes: | On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote: | | On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote: | On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote: | | * libtool.m4 (lt_cv_deplibs_check_method): Support Linux/mips. | | Before I waste any further time on it, is it any different from the | patch I rejected some months ago? It seems to still have the same | problem. | | I don't remember why you rejected it. | | The reason was that your patch enabled dependency tracking control | that is unnecessary for most GNU/Linux systems. It was only necessary | for old ARM systems whose glibc was broken. Then why wasn't this done explicitly in the first place? Why is there an incomplete test for architectures != arm when it is much more robust to make a single check for arm? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE GmbH, 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
