libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static lib containing backends


From: Ralf Wildenhues
Subject: Re: static lib containing backends
Date: Tue, 7 Feb 2006 11:09:43 +0100
User-agent: Mutt/1.5.11

* Yannick Lecaillez wrote on Tue, Feb 07, 2006 at 10:52:14AM CET:
> Ralf Wildenhues wrote:
> >* 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.

Likely for the full solution you will need to wait for libtool-2.0 (or
use the CVS version).

> Other thing, is there a way to compile libltdl using Visual C compiler ? 

Not yet.  You need the CVS version of Libtool plus the MSVC patch by
Peter Ekberg:
http://article.gmane.org/gmane.comp.sysutils.automake.general/6539

which we have not merged yet because it needs more testing; this patch
has seen lots of work on the libtool-patches mailing list.

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

Well, you can help with testing if you want.  Say so and I can probably
enumerate what needs to be done.  (Not for the faint of heart though.)

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

Hmm.  Do you want to be able to create the static version and a shared
version at the same time?

If not, it should be possible to do this (untested): if you want the
static library, make convenience archives from all backends.  I must
admit that I'm not certain that this
- works at the moment, nor
- can even be made to work portably.
We could add a TODO item for this, to look into it, but it will likely
take a little while.

If you could do with multiple `*.a' archives but are just trying to get
rid of the necessity of the `backend*.la' files: there is a pending
patch to fix this by Pierre Ossman; it still needs to be validated and
tested.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]