> * Пухальский Юрий Андреевич 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:) _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
