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

[Пухальский Юрий Андреевич]

> * Пухальский Юрий Андреевич wrote on Tue, Sep 06, 2005 at 08:52:57AM CEST:
> > > Oh, libtool recognizes this option fine.  It's Automake that forbids
> you
> > > to use it in *_LDFLAGS, because it adds a "-o liba.la" itself!
> > Actually it doesn't forbid. This option is added nicely to the command
> > line a bit later, so the latter will look something like:
> > ... -o liba.la ... -o la.o ...
> 
> Just because it looks like it works, doesn't meant that it works,
> and doesn't mean that it is forbidden.
Ok! I now know. Just didn't see, while not allow .o extension in 
xxx_LTLIBRARIES for partial linking and have with it libtool-generated targets 
for installing and uninstalling.

> 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). 
But thought, that libtool should try to link non-PIC objects if building PIC 
objects is disabled in configuration.

> Well, you can achieve that by changing, in my suggestion above,
>   la_o_deps = a.lo b.lo
> to
>   la_o_deps = a.o b.o
> 
> so you actually build non-libtool objects.
> Note, however, that this may be less portable.  OTOH, I don't think you
> need much portability if you are writing kernel modules.
Yes, this approach works. *sigh* Thought it will be as simple as using -o in 
LDFLAGS. 

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

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