This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
with kde.
It hangs on the last line, see below:

+ grep -E ^x86 archive import|^x86 DLL
"grep" hangs? That's truly bizarre.

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.)

Then I've taken a recent libtool from, build my profiler lib with
this (cvs dir tools/profiler from and copied this
libtool into the kde source tree.
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.

You really have to re-libtoolize the *actual* tree you are building.

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.
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 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
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.

Not gonna happen. See my reply to Max.

1b. this can be reached with a much easier way using the 'file' command:

deplibs_check_method="file_magic DLL|archive"
file_magic_cmd="file"> This needs equal time as "pass_all" (40 sec from make start until the link
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.

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 GOOD thing.

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. :-)
"For every complex problem there is an answer that is clear, simple, and wrong." -H.L. Mencken

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
4) other

Do NOT try to combine 2) and 3) -- which is what all of your suggestions in this email would do.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]