* Ralf Wildenhues wrote on Mon, Apr 04, 2005 at 09:06:25AM CEST:
* Robert Ögren wrote on Mon, Apr 04, 2005 at 01:30:26AM CEST:
With ash and lt_ECHO=printf...:
I think the disappointing speedup is caused by a lot of spawning of
printf (printf isn't a builtin in ash, right?) Setting
Hi Ralf,
Ralf Wildenhues wrote:
Hi Robert,
First I'd like to say many thanks for all your testing and valuable
feedback.
Thank you for the responses.
Will take a little while to work through all of it.
Hehe, sorry, I had too much time on my hands last weekend and largely
spent it on fiddling with
Ralf Wildenhues wrote:
libtool HEAD should tell you upon invocation of `autoconf -Wall' to
remove AC_LIBTOOL_WIN32_DLL in favor of adding the win32-dll option to
LT_INIT. After doing that, things should work. (But leaving things
like they are should also work.)
Unfortunately
[ upon reading Robert's mail again ]
* Tor Lillqvist wrote on Sun, Mar 27, 2005 at 03:00:14AM CEST:
Robert Ögren writes:
2. configure.in did not have AC_LIBTOOL_WIN32_DLL which now is required
for OBJDUMP to be set.
Hmm. Wasn't AC_LIBTOOL_WIN32_DLL supposed to be deprecated and
Ralf Wildenhues wrote:
[...]
Yes. We recently identified that an audit of libtool.m4 for wrong use
of $ECHO is necessary.
[details left out]
Another question: How did you find those bugs? I.e., were they exposed
by the Libtool testsuite? If not, how can we trigger them?
The testsuite triggers
Robert Ögren writes:
2. configure.in did not have AC_LIBTOOL_WIN32_DLL which now is required
for OBJDUMP to be set.
Hmm. Wasn't AC_LIBTOOL_WIN32_DLL supposed to be deprecated and
unnecessary? Or was it just that at some point it was de facto
unnecessary but never officially deprecated, and
Hi Robert,
* Robert Ögren wrote on Fri, Mar 25, 2005 at 01:24:52AM CET:
Ralf Wildenhues wrote:
Oh dear. This should be
CONFIG_SHELL=/bin/ash lt_ECHO='printf %s\n' /bin/ash configure [...]
instead.
This seems to mess up the result of func_win32_libid with recent libtool
from CVS
Hi Ralf,
Ralf Wildenhues wrote:
...
Yes. We recently identified that an audit of libtool.m4 for wrong use
of $ECHO is necessary.
Oops, I glanced over the thread index for the patches list but missed
that conversation.
If you have time to produce a patch to this extent for the system(s) you
can
I wrote:
I just configured and built glib-2.6.3 (from
ftp://ftp.gtk.org/pub/gtk/v2.6/) on Cygwin with
export SHELL=/bin/sh
export CONFIG_SHELL=/bin/sh
export lt_ECHO='printf %s\n'
I'm sorry for replying to myself, but there are some compatibility
issues with glib and Libtool HEAD that I
Hi again Ralf,
I finally have some numbers for you. The script I used is available at
http://libtool-cache.sourceforge.net/libtool-cache-bench.sh
What it basically does is to build GLib 2.6.3 using different versions
of libtool and with and without caching. As I said before, I'm usually
using
Ralf Wildenhues wrote:
Oh dear. This should be
CONFIG_SHELL=/bin/ash lt_ECHO='printf %s\n' /bin/ash configure [...]
instead.
This seems to mess up the result of func_win32_libid with recent libtool
from CVS (1.1888 2005/03/18 15:57:13). Instead of returning (echoing)
x86 archive import
it
Hi Max,
* Max Bowsher wrote on Tue, Mar 15, 2005 at 11:14:42PM CET:
Ralf Wildenhues wrote:
for your projects. For best results on Cygwin, you should probably
configure (with libtool HEAD) like
CONFIG_SHELL=/bin/ash lt_ECHO='printf %s' /bin/ash configure [...]
Oh dear. This should be
Hi Robert,
* Robert Ögren wrote on Mon, Mar 14, 2005 at 11:11:00PM CET:
I looked through the TODO thread from 2004-11 and saw some talk about
speeding up libtool. I'm particularly interested in improved compilation
speed on Cygwin (Windows). Is there any progress on this?
For the HEAD
Ralf Wildenhues writes:
Linking is a problem, though: shell wrappers break,
I have never liked (or understood...) libtool's shell wrappers or its
relinking on Win32. I always use --disable-static, I always run a
make install, and make sure the bin directory of the installation
location is in
Hi Tor,
* Tor Lillqvist wrote on Tue, Mar 15, 2005 at 10:32:41AM CET:
Ralf Wildenhues writes:
Linking is a problem, though: shell wrappers break,
I have never liked (or understood...) libtool's shell wrappers or its
relinking on Win32. I always use --disable-static, I always run a
make
Ralf Wildenhues wrote:
Hi Robert,
Hi Ralf,
For the HEAD branch of Libtool, I have made some changes that cause it
to fork less often. For the particular bad case I was looking at
(linking against ~500 objects), I got it from about 11 sec to about 5
sec, both of which include 2.5 sec of time spent
Ralf Wildenhues wrote:
for your projects. For best results on Cygwin, you should probably
configure (with libtool HEAD) like
CONFIG_SHELL=/bin/ash lt_ECHO='printf %s' /bin/ash configure [...]
(replace /bin/ash with the path to Cygwin's Almquist shell clone).
That path would be /bin/sh, so it's
Hi everybody,
I looked through the TODO thread from 2004-11 and saw some talk about
speeding up libtool. I'm particularly interested in improved compilation
speed on Cygwin (Windows). Is there any progress on this?
A while ago I created a temporary solution for myself which caches the
commands
18 matches
Mail list logo
