Re: static lib containing backends

[Yannick Lecaillez]

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 :-/

> >   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?
>  
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 :-)).

> 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?
>  
Exactly, i don't want impose usage of libtool for application which use 
my lib.

Thanks for your interest !

   Regards,
   Yannick.