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" 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 static"
Not gonna happen. See my reply to Max.
butAgain, 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:
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)
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.
"For every complex problem there is an answer that is clear, simple, and wrong." -H.L. MenckenChuck, 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
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/
