libtool
[Top][All Lists]
Advanced

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

Re: Problem with "fixed" -static flag


From: Gary Kumfert
Subject: Re: Problem with "fixed" -static flag
Date: Fri, 13 Jan 2006 11:02:06 -0800 (PST)


Hi Ralf,

On Fri, 13 Jan 2006, Ralf Wildenhues wrote:

> Hi Gary,
>
> * Gary Kumfert wrote on Thu, Jan 12, 2006 at 09:07:52PM CET:
> >
> > I'm learning that libtool 1.5.22 "fixed" the -static flag so that
> > static libraries are linked in the build directory, but
> > shared libraries in the install directory.  But I don't
> > understand why this is considered "better" behavior.
>
> The discussion was controversial:
> http://thread.gmane.org/gmane.comp.gnu.libtool.general/6573
> http://thread.gmane.org/gmane.comp.gnu.libtool.patches/5636
> and references therein.
>
> > The side-effect is that libtool behaves very
> > differently between "make check" and "make installcheck"
> > ...particularly in my case, since the libraries being linked
> > have #ifdef PIC preprocessor directives in their source.
>
> Yep.  Not very nice.  Matches the documentation though, and the
> pre-1.5 behavior of libtool, quoting (Link mode):
> | `-static'
> |      If OUTPUT-FILE is a program, then do not link it against any
> |      uninstalled shared libtool libraries.  If OUTPUT-FILE is a
> |      library, then only create a static library.


So, you changed behavior that's been established for years
only because the documentation and code differed?
Wouldn't it have been easier to just fix the documentation?

> > I thought the -all-static flag would be a solution, but it
> > seems to go too far... trying to link in *every* library (even
> > system libraries) statically.
> > glibc (and other libs that dlopen modules internally) protest
> > vociferously on the link line (how do they do that?) and
> > ultimately break my build.
>
> Yep, I see that in quite a few cases, too.  Also, link_static_flag is
> not correctly determined for some systems (we have a TODO item about
> that).
>
> > I'm at the point of hacking in my own -lt-static flag to
> > reproduce the old behavior of -static.... but first I wanted
> > to do a sanity check.
> >
> >   1. Am I the only one who prefers the older behavior?
>
> See above.
>
> >   2. Is there another way to make just the libtool libraries static
> >      after they've been installed?
>
> I don't understand this question.  What is the reason that prevented you
> from creating just a static library for these ones in the first place?

Yes, I suppose I didn't give enough information to motivate why I want to
do what I do... I was hoping there was some "undocumented" backward
compatibility feature.

I'm going to fudge a bunch of details to keep this email short, but
essentially I have two kinds of libraries:  implementations
and proxies.  libXXX_impl.{a,so} has the
real implementation of some software components, and they could
be in any language (C,C++,Fortran,Python,Java,etc.)  Langauge-specific
proxies are required to make calls on these components.  These proxies
are generally useful, so we also put these in libraries, say
libXXX_proxy_c.{a,so}.

To support both dynamic loading and static linking of the impls,
proxies have "#ifdef PIC" regions in them to behave two different ways.
If they're static libraries, PIC isn't #defined, and they directly
reference symbols in  libXXX_impl.a assuming it too is statically
linked.  If they're shared libraries, PIC is defined, and they
make no direct reference to symbols in libXXX_impl.so, but instead
dlopen the module.

Now, when I do "make installcheck" with the new libtool behavior,
the drivers for static tests should be linked against the
libXXX_stub_c.a & libXX_impl.a.  Instead it gets linked against
libXXX_stub_c.so which wants to dlopen things, but isn't given
the RPATH, so it fails.

> >   3. Could there be an alternative way to structure the libraries?
>
> I haven't yet fully grasped your needs.  A couple of questions in
> return:
>
> - Would it be sufficient if libtool implemented per-deplib
>   `-Bstatic/-Bdynamic' (whatever they're called) switches?

I can imagine this may be useful (you can never have too much
control when you really need it), but its unnecessarily complex
for my immediate needs.  Generally, our users either want all
dynamic-loaded modules for flexibility (&access from interpreted
languages), or all static for speed.

> - The former is not so easy to implement, so: as an easier measure,
>   were the former 1.5.x semantics of `-static' exactly those you
>   needed?  Maybe we should just implement another option to get
>   those semantics again, as you suggested above.  I wouldn't name
>   it `-lt-static' though.  Maybe `-static-libtool-libs' would fit
>   better, but it's rather long.

Yes.  I think this would be fine.  I'll leave it to you to
pick the name.  I'm only going to write it once in a sed
command to my Makefiles.

Thanks,

Gary




reply via email to

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