This is the mail archive of the
mailing list for the Cygwin project.
RE: [avail for test] libtool-devel-20030121-1
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "Charles Wilson" <cwilson at ece dot gatech dot edu>
- Cc: <cygwin at cygwin dot com>
- Date: Sun, 9 Feb 2003 02:12:28 +0100
- Subject: RE: [avail for test] libtool-devel-20030121-1
> 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:
+ newdeplibs= -L/usr/lib/w32api
+ expr -lbz2 : -l\(.*\)
+ test bz2 !=
+ test bz2 != 0
+ test Xyes = Xyes
+ test -n -lbz2
+ eval $echo "lib$name"
+ echo libbz2
+ ls /usr/lib/w32api/libbz2[.-]*
+ ls /usr/lib/libbz2.a /usr/lib/libbz2.dll.a
+ ls -lLd /usr/lib/libbz2.a
+ grep ->
+ 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.
*** 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
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
If you need executables too use deplibs_check_method="file_magic
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. :-)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html