|
From: | Yannick Lecaillez |
Subject: | Re: static lib containing backends |
Date: | Tue, 07 Feb 2006 10:52:14 +0100 |
User-agent: | Mozilla Thunderbird 0.7.3 (X11/20040803) |
Ralf Wildenhues wrote:
Hi Yannick,* Yannick Lecaillez wrote on Sat, Feb 04, 2006 at 01:37:52PM CET:Application ---> libA <-----> lib Backend Everything works pretty well in a shared lib environment.This is not true. Everything works well in ELF shared library environments. Your setup breaks in shared library environments where undefined symbols are not allowed at link time. This includes AIX without runtimelinking, and win32 systems, for example. The usual way to solve this is described in the CVS version of the Libtool manual, in the node 'Linking with dlopened modules'.
Thanks ! i'll test that.Other thing, is there a way to compile libltdl using Visual C compiler ? Someone reported to me that just failed. Its why we currently use our own libloader stuff for win32 arch and made
this arch a specific case :-/
Because have .la files add absolutly nothing more than dependency in our case. I want client program be able to just static link their app to the libA and have something which work. I don't want impose client app to use libtool. More over have libA.a, libBackend1.a, libBackend2.a, etc ... simply make no sense since _nothing_ other than libA need to be linked against libBackendn.a libBackendn.a haven't got any reason to exists (shared ones have, of course :-)).I want be able to supply a static lib A which doesn't depend on any .la file and which contain all backend staticly :Why do you want to be able to do that?
Exactly, i don't want impose usage of libtool for application which use my lib.Maybe I can suggest something better (that also does not need backend_symbols.c), but I would like to understand the problem you are really trying to solve first. Is your interest that users of libA will not use libtool at all?
Thanks for your interest ! Regards, Yannick.
[Prev in Thread] | Current Thread | [Next in Thread] |