This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
Ralf Habacker wrote:
Ralf -- please drop my 'final' script into one of your generated
libtools and run your tests (what? rebuilding KDE?) on it, and let me
know what you think. (Oh, and since (a) 'file' execution speed is
invariant with target size, and (b) we match *DLL* and *executable*
separately, if you are linking directly to DLLs -- as I believe Ralf's
KDE build does -- then my version is almost as fast (<1% difference) as
Ralf's "check the name of the file only" version)
Chuck, this script does not work with original libtool 1.4e, which is provided
It hangs on the last line, see below:
"grep" hangs? That's truly bizarre.
+ grep -E ^x86 archive import|^x86 DLL
But, you'd need to relibtoolize the whole KDE tree with a modern version
of libtool, as I describe in the other message. This particular test
you have done is not helpful (but that's my fault -- I'm sorry I
suggested "kde" as a test base. I had thought you were *already*
relibtoolizing with modern libtool; I did not realize you were building
KDE using the KDE-supplied, 1 year old version of libtool.)
Now that's better, but...not quite. See, there have also been changes
in libtool.m4 -- which means that after you run aclocal and autoconf,
your configure script is different. It sets different variables, it
sets the same variables to possibly different values, etc etc.
Then I've taken a recent libtool from www.cygwin.com, build my profiler lib with
this (cvs dir tools/profiler from http://kde-cygwin.sf.net) and copied this
libtool into the kde source tree.
You really have to re-libtoolize the *actual* tree you are building.
I believe this is because of the libtool.m4 --> configure script changes
that you did not pick up, using your method of snarfing a different
project's prebuilt libtool.
The results for makeing for example kdecore:
pass_all: 40 sec from make start until the compile command line comes up.
file_magic (win32_libid): 50 sec from make start until the ar(!) command line
comes up. The problem I've got with this is that I can't build a shared library.
Instead I've got some errors.
ARGH. This defeats the whole purpose of the policy change -- and it is
a policy change driven by the libtool development. I don't want to
support a forked version of libtool that differs from mainline on a
basic policy issue.
The only way I see to fix it is to add static archives to deplibs_check_method:
deplibs_check_method="file_magic ^x86 archive import|^x86 DLL|^x86 archive
Not gonna happen. See my reply to Max.
Again, you're just saying "pass_all" by another name. You avoid the
(untested) codepaths within libtool this way, but you're still reverting
the official libtool policy.
1b. this can be reached with a much easier way using the 'file' command:
This needs equal time as "pass_all" (40 sec from make start until the link
And if you think about it long enough, you'll probably agree that the
libtool folks' decision to prevent dynlibs depending on statlibs is a
"For every complex problem there is an answer that is clear, simple, and
wrong." -H.L. Mencken
Chuck, what kind of advantage do you see in win32_libid against this.
win32_libid makes this stuff more complicated as it is (see 1.), so I vote for
skipping the win32_libid command complety and using the 'file' command. It seems
obsolate to me.
I'm sorry, that you may be frustrated about the work which is already done, we
can learn from this: Do not make things complexer as they are. :-)
The big slowdown in win32_libid() is using objdump and nm to help
determine that a given "foo.a" file is (1) an archive, (2) an archive of
x86 objects, and (3a) an archive of x86 IMPORT objects, or (3b) and
archive of x86 STATIC objects.
You are trying to argue that we don't really need to distinguish between
(3a) and (3b) -- so just drop the whole $objdump and $nm thing. BUT
THAT IS NOT POSSIBLE -- unless we want to VIOLATE the policy: Thou shalt
not create dynamic libraries that have static dependencies.
Ain't gonna happen. Find me a faster way to distinguish between x86
import libs and x86 static libs (and random-other-architecture libs of
any sort), and I'll thank you.
But telling me that I must support a fundamental philosophical and not
merely technical fork of libtool for the foreseable future is NOT an option.
As I see it, you have two problems:
1) my detection code is too slow for your taste, and
2) that very detection sometimes causes your build to fail, because
you are trying to build dynlibs with static dependencies.
So, you have two reasons to try to get win32_libid() OUT, or replace
file_magic with pass_all, or whatever. Unfortunately, (2) is NOT my
problem. You want to build dynamic libraries? Make sure all of your
dependencies are dynamic. You want win32_libid() to go faster? Great,
me too -- but don't optimize it into a no-op. It has a purpose. It
needs to perform that purpose -- which is classifying objects into these
four categories (not three, not two, FOUR):
1) x86 DLL (and EXE)
2) x86 archive static
3) x86 archive import
Do NOT try to combine 2) and 3) -- which is what all of your suggestions
in this email would do.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html