Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <415C41F3.7070706@x-ray.at> Date: Thu, 30 Sep 2004 19:27:15 +0200 From: Reini Urban User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040817 MIME-Version: 1.0 To: cygwin Subject: Re: libtool convenience libs problem References: <415C3D27 DOT 8060801 AT x-ray DOT at> In-Reply-To: <415C3D27.8060801@x-ray.at> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/