[Top][All Lists]

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

Re: exclusive static or shared

From: Christopher Hulbert
Subject: Re: exclusive static or shared
Date: Fri, 17 Feb 2006 14:21:07 -0500

I normally do not create shared libraries.  The ONE place I do though
is with Matlab MEX functions which are nothing more than a shared
library with the mexFunction as an exported function.  I link my
Matlab code against static libraries that contain my real functions
(The matlab interface serves exactly that an interface from matlab to
my C/fortran backend).  Although it's not advised it works on 3 main
platforms that we use matlab on x86,x86_64,and win32.  The
comment/suggestion was not a necessity, but would facilitate my option
as a user/developer to build both shared and static libraries and be
able to link the Matlab code against either (without separate builds).
 It's really no big deal though.  Maybe this little spiel will give
you an idea of where I start doing wacky things with libtool :)!

On 2/17/06, Ralf Wildenhues <address@hidden> wrote:
> Hi Christopher,
> * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:10:20PM CET:
> >
> > Lets say I build library liba as both static and shared (thus I have
> > liba.a and or liba.lib and liba.dll).  I later want to build
> > or libb.dll against the installed liba.  From my observations
> > it always takes the shared liba.  Is this true, or is there a flag to
> > tell it to use static libraries where available (similar to -i-static
> > for intel compiler).
> >
> > I was thinking something like -libtool-static or
> > -libtool-static=-la,-lxyz where the comma-separated list is a list of
> > libraries this rule applies to.  Any thoughts on the matter?
> Yes, there are some thoughts:
> First, don't let shared libraries have static libraries as dependencies.
> It's a pain, there are many systems where this will not work as desired,
> and making sure you never end up with duplicate symbols and/or arising
> subtle bugs is not easy.  Text relocations cost shareability and lots
> of memory on some systems, and if they cause a sufficient speedup, it
> usually means your interface design is broken.  Surely I acknowledge
> that on _some_ systems things may be differently, but Libtool is about
> portable library creation.  And after all, it is possible to achieve
> this now by the workaround of creating several instances of a library
> (don't bother us with bug reports then, though; I won't read them).
> On systems without pass_all, libtool will not actually _include_ the
> static library into the shared one, though, but record the dependency
> in the .la file so that it can be fulfilled when a program is created.
> Second, there was recently a longish thread about per-deplib static/
> shared flags for creating programs, including patches.  Likely, soon
> after 2.0 is released some progress on that issue can be expected.  ;-)
> Third, there is a pending patch implementing `-static-libtool-libs',
> to be applied before 2.0 hopefully.
> Cheers,
> Ralf

reply via email to

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