Isn't that the old zsh qouting bug? Well, people still refuse to give us
an 1.4.3 anysoon, so may be you want to expand your configure scripts with:
http://ac-archive.sf.net/Installed_Packages/patch_libtool_on_darwin_zsh_overquoting.html
Christoph Egger wrote:
Usually I don't reply myself, but
no news
Troy Cauble wrote:
Using 1.4.2, I was bitten by the test/pic_mode quoting bug
in ltmain.sh.
I pulled branch-1-4 from cvs but for that version, ltmain.sh
needs ${SED} defined by a new macro and still has issues with
non-quoted test values anyway.
After realizing that I
Isn't that the old zsh qouting bug? Well, people still refuse to give us
an 1.4.3 anysoon, so may be you want to expand your configure scripts
with:
http://ac-archive.sf.net/Installed_Packages/patch_libtool_on_darwin_zsh_overquoting.html
zsh? Is that yet another shell?
I use the bash shell.
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
file.
Having a closer
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'
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
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
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'
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
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
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
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
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
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/$soname $verstring'
by
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
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
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
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
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/$soname
35 matches
Mail list logo
