Re: Problem with "fixed" -static flag

[Ralf Wildenhues]

Hi Gary,

Thanks for the reply!

* Gary Kumfert wrote on Fri, Jan 13, 2006 at 08:02:06PM CET:
> On Fri, 13 Jan 2006, Ralf Wildenhues wrote:
> > * 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:

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

> So, you changed behavior that's been established for years
> only because the documentation and code differed?

No.

> Wouldn't it have been easier to just fix the documentation?

As far as I know, in fact the behavior we have now had been established
for years, and documented, up to 1.4.x.  Then came 1.5.x and changed the
implementation -- I must admit to not know the reason now -- but not the
docs.

Users were surprised at the "new" semantics and complained.  We changed
back.  So now you complained (rightfully) -- same thing again, other way
round.

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

Oh, ok.  Thanks for the description, by the way.  I do have an old
version of babel lying around, but keep forgetting about its internals.

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

OK, good.

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

OK.  Would you be willing to write and/or test a patch to this extent?
It shouldn't be hard: the patch that changed to the current behavior is
very small (see referenced threads).  Writing a test to make sure it
works as designed would be very helpful.

Cheers,
Ralf