Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <415C41F3.7070706@x-ray.at>
Date: Thu, 30 Sep 2004 19:27:15 +0200
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040817
MIME-Version: 1.0
To: cygwin <cygwin AT cygwin DOT com>
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

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/