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
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
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
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
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
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
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
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
| 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
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*
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
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
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
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
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
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
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
| 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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
. 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
.
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
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
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,
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
[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 --
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
43 matches
Mail list logo
