This is the mail archive of the
mailing list for the Cygwin project.
RE: [avail for test] libtool-devel-20030121-1
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "Charles Wilson" <cwilson at ece dot gatech dot edu>,<cygwin at cygwin dot com>
- Date: Wed, 5 Feb 2003 09:31:15 +0100
- Subject: RE: [avail for test] libtool-devel-20030121-1
> Yes, Ralf, I know. This is like the sixth iteration trying to solve
> this problem. The very first attempt did what you suggest (only it is
> much much more complicated than you imply; you're overlooking a lot).
> However, that fix was unacceptable to the automake and libtool people.
> Hence, tries #2, #3, #4, #5, and this one.
> Please don't go over old ground, since you've been ignoring the onging
> discussion which I have CC:ed to the cygwin and mingw lists throughout.
> I am not interested in doing it another way -- I've already done it
> three different ways (with various refinements, leading to a total of
> six attempts). I am interested in bug reports and fixes for this method.
> And if I sound annoyed, I am: I expected better from you. I would have
> thought that you, given your KDE work, would have been very interested
> in the *on-going* development -- and not content merely to sit back and
> ignore the whole thread, and then chime in after the fact with old ideas.
Chuck, about two month ago we had a private discussion about the file_magic
stuff, where i have investigated about 7 hours to figure out a faster approach
for identifing import library file types, because the implementation you have
mentioned would increase the kde compiling time more than about 70 % (that means
6,8 hours instead 4 hours for a full recompile, which is inacceptable for me).
Probably you remember this stuff, if not I can send you the thread. So it seems
to me, that you only like to get my confirmation about your solution and nothing
>I realize that ANY slowdown is painful, but at least these checks are
>not performed when linking (and relinking and relinking and ...)
>executables. They only apply when building sharedlibs, and those happen
>only once per build. Unlike exe's. Sigh.
This may be true for small applications and with small number of dll's but not
for kde as it
contains about 200 dll's and 100 exe's. (see timing example above)
May be you'r right with your point of view, but this would throw back me very
much, so I had decided to stop this thread. (I'm using pass_all currently, it
works for me)
Instead I begun to think about how to solve this problem in a general way and
the result is the auto-import-from-dll-stuff (probably you don't know this
cause), so this may not be wath you have expected, but think about if this isn't
also a good contribution.
Additional you know that the libtool is very complicate and someone need very
deep knowledge about this stuff to handle with this. At that time I couldn't
investigate more time to enter the same knowledge level as you to give a
In the last two weeks I've started fixing the kde3 build system and have to go
very deeply into libtool and friends, so now I'm feeling comfortable again with
this stuff and so I could give the above mentioned input and that probably for a
time windows of about the next month. not earlier, sorry. This is reason for the
contribution right now.
Third, I have stated more than one time, that kde uses an older libtool/automake
(kde3 for example libtool 1.4e, automake 1.5/1.6) release and so following the
on-going process makes not very much sense for me (because of limited time).
Instead I have to fix bugs in that releases and from the growing knowledge I can
Fourth: Chuck, the problem in the last two month was, you haven't asked, if I
have time for handling this, you only have started some threads and requested
like "... need input" and you have expected, that I have the libtool knowledge
all the days, which isn't true. If you would have asked, I would have said:
Please wait until I'm going to the kde3 build fix and than I can help. Sorry.
Fifth: I have never seen a man like you, who is able to write so very detailed
and deals so fast with such complicated stuff, that sometime a lamp goes on,
which is named "overload". :-)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html