>
>
> Bruce Korb wrote:
> > Christoph Egger wrote:
> >
> >
> >>Ok, here we come: I just did 2)
> >>The fix is replacing this line
> >>
> >>archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> >>echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> >>$deplibs$linker_flags -i
Bruce Korb wrote:
> Christoph Egger wrote:
>
>
>>Ok, here we come: I just did 2)
>>The fix is replacing this line
>>
>>archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
>>echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
>>$deplibs$linker_flags -install_name $rpath/$sona
> While we're on the subject of darwin and libtool, we've been needing to
> make changes to libtool to make KDE compile on darwin that haven't been
> discussed in this thread.
>
> Darwin's GCC has a number of very weird states it can get into during
> the linking stage because of it's crappy ld (
While we're on the subject of darwin and libtool, we've been needing to
make changes to libtool to make KDE compile on darwin that haven't been
discussed in this thread.
Darwin's GCC has a number of very weird states it can get into during
the linking stage because of it's crappy ld (grin), and I
> In regard to: Re: libtool 1.4.2 on Darwin, Christoph Egger said (at
> 11:26pm...:
>
> >Ok, here we come: I just did 2)
> >The fix is replacing this line
> >
> >archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> >echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> >$depli
> Christoph Egger wrote:
>
> > Ok, here we come: I just did 2)
> > The fix is replacing this line
> >
> > archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> > echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> > $deplibs$linker_flags -install_name $rpath/$soname $verstri
In regard to: Re: libtool 1.4.2 on Darwin, Christoph Egger said (at 11:26pm...:
>Ok, here we come: I just did 2)
>The fix is replacing this line
>
>archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
>echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
>$deplibs$linker_flags -i
Christoph Egger wrote:
> Ok, here we come: I just did 2)
> The fix is replacing this line
>
> archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> $deplibs$linker_flags -install_name $rpath/$soname $verstring'
>
> by this
> Christoph Egger wrote:
> >
> > All what I want are three things:
> >
> > 1) That my above fix becomes part of one of the next libtool releases
> > 2) That libtool calls gcc with the right params, so that gcc doesn't
> break
> > the compiling process with 'gcc: -install_name only allowed with
>
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
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 an
Christoph Egger wrote:
>
> All what I want are three things:
>
> 1) That my above fix becomes part of one of the next libtool releases
> 2) That libtool calls gcc with the right params, so that gcc doesn't break
> the compiling process with 'gcc: -install_name only allowed with
> -dynamiclib'
> >>Christoph Egger wrote:
> >>
> >>I am running Darwin 6.1. libtool 1.4.2, autoconf 2.52 and automake
> >>1.6.1 are shipped with it.
> >>
> >>The application I write loads dynamic libs at runtime or at least it
> >>should.
> >>But Darwin says, the dynamic lib are not of the right type of object
>
I've installed CVS libtool to wrong directory so aclocal used different
libtool.m4. My mistake, now everything works fine.
Thank you for your help.
Martin
Ossama Othman wrote:
> Hi,
>
> On Mon, Oct 07, 2002 at 07:01:04PM +0200, Martin Frydl wrote:
>
>>progname=`$echo "$0" | ${SED} 's%^.*/%%'
38 matches
Mail list logo
