Re: libtool convenience libs problem
Hi Reini, So do I have to rebuild flex just to support a dynamic lib, which uses some parser generator support? 2000-01-19 Thomas Tanner [EMAIL PROTECTED] * ltmain.in: rewrite of the ILD code, merge linking code for programs, libraries and objects, allow linking of shared libraries against static libraries/objects on platforms that support it but print a warning, fix some typos It was already implemented in libtool. If all fails, try to set pass_all at the right place so this check is 'skipped': if test $deplibs_check_method != pass_all; then ...don't link... else ...link... The only reason I see why it is not or just partially supported by libtool is that it doesn't work on platforms where is a real difference between PIC and nonPIC code. THere is also a thread n the archives where Charles explains why the pass_all flag is not default for Cygwin. Gerrit -- =^..^= http://nyckelpiga.de/donate.html -- 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/
Re: libtool convenience libs problem
Gerrit P. Haase schrieb: So do I have to rebuild flex just to support a dynamic lib, which uses some parser generator support? 2000-01-19 Thomas Tanner [EMAIL PROTECTED] * ltmain.in: rewrite of the ILD code, merge linking code for programs, libraries and objects, allow linking of shared libraries against static libraries/objects on platforms that support it but print a warning, fix some typos It was already implemented in libtool. If all fails, try to set pass_all at the right place so this check is 'skipped': if test $deplibs_check_method != pass_all; then ...don't link... else ...link... The only reason I see why it is not or just partially supported by libtool is that it doesn't work on platforms where is a real difference between PIC and nonPIC code. THere is also a thread n the archives where Charles explains why the pass_all flag is not default for Cygwin. yes, that would be interesting to read, because I'm wondering what prevents libtool on cygwin to ignore the duplication of efforts providing PIC (in .libs) and nonPIC objects, where both are effectively the same. And then refuses to build on false assumptions. (PIC != non-PIC on cygwin) Maybe some src defines are in effect for the .libs/ which could hurt. (or did hurt before the improved binutils) So far I found nothing, but charles has a lot of messages in the archive to explore. I'll start with the libtool demo's from the src packages. mdemo-shared looks promising. for now I live this ugly workaround: extract the objects from the static lib, copy them (as fake) to the PIC objects, and build my module. -- 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/
Re: libtool convenience libs problem
Hi Reini, There is also a thread n the archives where Charles explains why the pass_all flag is not default for Cygwin. yes, that would be interesting to read, because I'm wondering what prevents libtool on cygwin to ignore the duplication of efforts providing PIC (in .libs) and nonPIC objects, where both are effectively the same. And then refuses to build on false assumptions. (PIC != non-PIC on cygwin) Maybe some src defines are in effect for the .libs/ which could hurt. (or did hurt before the improved binutils) So far I found nothing, but charles has a lot of messages in the archive to explore. I'll start with the libtool demo's from the src packages. mdemo-shared looks promising. Search for 'pass_all +Charles' via Google. for now I live this ugly workaround: extract the objects from the static lib, copy them (as fake) to the PIC objects, and build my module. That is likely the same as if you would use pass_all, but pass_all is cheap, just a small fix in libtool.m4 or if you prefer to not modify system libs then fix it in aclocal.m4 before running autoconf. Gerrit -- =^..^= http://nyckelpiga.de/donate.html -- 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/
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. 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/
Re: libtool convenience libs problem
sorry for repating to myself. But others had the same concerns this week http://lists.gnu.org/archive/html/libtool/2004-09/msg00124.html And I'm also not convinvced that the given answer is practical. The static lib uses probably non-PIC code so it cannot be linked in. Convenience libs should be avoided, rather link all objects directly. and then do it via ld -r but libtool doesn't allow the setting of such an ld flag. And I don't want to maintain the multiple dllwrap mess as before. Esp. when it will not be accepted upstream. So do I have to rebuild flex just to support a dynamic lib, which uses some parser generator support? Reini Urban schrieb: 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/
