This is the mail archive of the cygwin 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]

libtool convenience libs problem

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.

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).

$ ../libtool --mode=link --tag=CC gcc -O2 -o -version-info 1:0:0 -no-undefined -rpath /usr/lib actioncompiler/ blocks/ *.lo
rm -fr .libs/libming.a .libs/ .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

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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