Mail Archives: cygwin/2003/02/09/00:17:56
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 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.
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
> static"
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.
> but
> 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
> command)
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.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -