Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Ralf Habacker" To: "Charles Wilson" Cc: Subject: RE: [avail for test] libtool-devel-20030121-1 Date: Sun, 9 Feb 2003 02:12:28 +0100 Message-ID: <005b01c2cfd8$5036a800$0a1c440a@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3E44B81C.20108@ece.gatech.edu> > 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: + newdeplibs= -L/usr/lib/w32api + expr -lbz2 : -l\(.*\) + name=bz2 + test bz2 != + test bz2 != 0 + test Xyes = Xyes + test -n -lbz2 + eval $echo "lib$name" + echo libbz2 + libname=libbz2 + ls /usr/lib/w32api/libbz2[.-]* + potential_libs= + ls /usr/lib/libbz2.a /usr/lib/libbz2.dll.a + potential_libs=/usr/lib/libbz2.a /usr/lib/libbz2.dll.a + ls -lLd /usr/lib/libbz2.a + grep -> + potlib=/usr/lib/libbz2.a + test -h /usr/lib/libbz2.a + eval win32_libid "$potlib" + /usr/bin/sed 10q + grep -E ^x86 archive import|^x86 DLL 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. 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. 1. *** Warning: linker path does not have real file for library -lutil. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libutil and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libutil.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. /usr/lib/libutil.a is a nonlibtool static archive, which isn't catched by your script. This results into a linker fail with an "undefined reference" error, because a function of this lib is needed. 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" 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) If you need executables too use deplibs_check_method="file_magic executable|DLL|archive" 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. :-) Ralf -- 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/