This is the mail archive of the
mailing list for the Cygwin project.
libtool convenience libs problem
- From: Reini Urban <rurban at x-ray dot at>
- To: cygwin <cygwin at cygwin dot com>
- Date: Thu, 30 Sep 2004 19:06:47 +0200
- Subject: libtool convenience libs problem
I don't where to direct libtool cygwin specific questions to, so I try
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
Or should I declare -dlopen for my main lib?
Sounds wrong because the problem is that it doesn't link the libfl.a
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 libming.la -version-info
1:0:0 -no-undefined -rpath /usr/lib actioncompiler/libactioncompiler.la
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html