libtool convenience libs problem

Reini Urban rurban@x-ray.at
Thu Sep 30 17:40:00 GMT 2004


I don't where to direct libtool cygwin specific questions to, so I try 
it here.

I have an already libtoolized library, which should produce a DLL,
where several subdirs are just "convenience libs".
$ pinfo libtool
 > Node: Static libraries

Such a convenience lib (a bastard between a real shared and static for 
intermediate usage, as I understand), depends on -lfl, which is only 
static. (some unimportant flex helpers)

Now when I try to link the main lib (libtool -mode=link) to create the 
DLL, the .la in the convenience libs contains -lfl, which is passed to 
the main lib linker verbatim, which creates a conflict in the link step, 
because -lfl cannot be linked dynamically, which causes the whole lib to 
be linked static only. Right? Sounds wrong to me.

I thought libtool is clever enough to resolve this dependency and just 
link those objects directly to the libfl.a objects, and just the rest 
dynamically via __imp stubs.

So it looks like that I have to persuade the convenience linker step 
somehow to link the static lib directly. dlopen or dlpreopen (as 
described in the warning) does not help, because there no cygfl.dll to 
load later.
Or should I declare -dlopen for my main lib?
Sounds wrong because the problem is that it doesn't link the libfl.a 
objects statically.
Or should I declare the convenience libs -static? Doesn't help neither.
I really don't want to extract the libfl.a objects and link it into the 
intermediate lib just to please libtool.

Example:
The two subdirs are just convenience libs (linked without -static and 
-rpath), where one depends on -lfl, the other on -lz (where a DLL exists).

/usr/src/libming/libming-0.3b2_20040929/.build/src
$ ../libtool --mode=link --tag=CC gcc  -O2 -o libming.la -version-info 
1:0:0 -no-undefined -rpath /usr/lib actioncompiler/libactioncompiler.la 
blocks/libswf.la *.lo
rm -fr  .libs/libming.a .libs/libming.la .libs/libming.lai

*** Warning: linker path does not have real file for library -lfl.
*** 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 libfl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libfl.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.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list