Re: partial linking with non-PIC objects (was: Strange behaviour in libtool-1.5.20)

[Ralf Wildenhues]

Hi Yuri,

* Пухальский Юрий Андреевич wrote on Tue, Sep 06, 2005 at 12:02:46PM CEST:
> > * Пухальский Юрий Андреевич wrote on Tue, Sep 06, 2005 at 08:52:57AM CEST:


> > Ahh, ok, now we're making progress, and I see the failure.
> > I did not understand that you want to link non-PIC objects partially.
>
> Yes. One thing, that there is no PIC in recommended flags for kernel
> module building (and it actually hindered somewhere!). Second thing,
> that I have certain configuration aimed to producing a VxWorks module
> - I just don't need twice build time to build pic objects (so
> --disable-shared is used). 

If you used --disable-shared just for this reason, you even should be
able to omit that now.

> But thought, that libtool should try to link non-PIC objects if
> building PIC objects is disabled in configuration.

Well, libtool originally uses partial linking only as a measure to evade
command line length limits.  They come up with shared libraries in this
setting.  With static libraries (or convenience archives, FWIW), it is
possible to use build archives in steps, so no partial linking is
necessary here.

> > > Because I must use the same set of objects, although not from .libs/,
> > > but from ./ directory. And I'm restricted to use the convenience
> > > libraries being compiled in this directory. I cannot use nested
> > > libraries, because the dependencies are stored in .la file (either I
> > > must parse it... recursively..., etc.) Which destroys the main goal of
> > > libtool - convenience.
> > 
> > Hmm, I believe now you hint at another problem you encounter.
> > But this problem I have not understood yet -- maybe you need
> > to explain more.
>
> No, it was only pointing at the difficulties of not using libtool
> while making partial linking:) You have shown me the way to evade this
> while still linking with libtool.

OK, good.

> > And, by the way, the main goal of libtool is to allow portability. :)
> Erm. Yes, surely! Convenience in achieving portability.

:-)

> > How about now?  :)
> Yes. Thank You! And sorry, that it didn't turn out to be a bug, but a
> feature:)

Well, from your point of view it is a limitation.  I gave an explanation
for _why_ libtool has this limitation above.  Since it is possible to
work around the limitation, I do not see much need to change Libtool.
No reason to be sorry, by the way, it's actually a good thing when bugs
turn out to be non-bugs.  :)

Cheers,
Ralf