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.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
