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 -- 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
+ 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, build my profiler lib with
this (cvs dir tools/profiler from 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:

deplibs_check_method="file_magic DLL|archive"

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:
Bug reporting:

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