In regard to: libtool 1.4.3 searches /usr/lib before -L, 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
ha
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-fre
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 com
| > 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 grieve
> 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
> 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 Au
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 peop
> 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 li
| > 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
[Cc trimmed]
> 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.
In the mean time, we are happy to pursue our use of
autoconf 2.13.
> Sasc
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
On 9 Oct 2002, Akim Demaille wrote:
> 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 compat
> "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
> "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
> "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 hittin
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
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 c
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
"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?
|>
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.
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 rol
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:
> -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
[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 -- develop
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. W
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 las
> 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 l
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
> > immediate
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
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
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
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 fi
Earnie Boyd <[EMAIL PROTECTED]> writes:
> 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.
autoconf 2.5x w
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
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 al
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 Li
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 fi
> > 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 i
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
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 an
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
> "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 bi
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.
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 consis
44 matches
Mail list logo
