* Пухальский Юрий Андреевич 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. > So no problem with it, the problem (and with your approach as well), > that there is no convenient way to install/uninstall the resulting > object. But well, it's not the main problem, the main problem is that > I cannot build this object at all!:) Installing is also pretty easy: write an install-exec-local rule for this, and an uninstall-exec-local rule. > > Just write the rule yourself, like this: > > > > la_o_deps = a.lo b.lo > > la.o: $(la_o_deps) > > $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ > > --mode=link $(CC) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ > > $(la_o_deps) > It (of course) doesn't work either (with --disable-shared). > Actually, the line: > libtool --tag=CC --mode=link gcc -g -O2 -o la.o a.lo libb.la > doesn't work, when we are configured with --disable-shared. The a.o object > gets omitted. > That's what I wrote before. 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. 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. > > > Then I had to make a kernel module for Solaris, which is in fact > > > partially linked object too, and I wondered whether I can specify > > > additional linker flags to it (it turned out, that I cannot specify > > > any, because partial linking is considered unportable). Now I just > > > wonder what this feature is for:))) > > > > Well, it's not too unportable, many systems have it in one way or > > another. It's just not very useful either, except to work around > It's very useful to simplify the Makefiles. I ought to use the > following workaround, which is ugly as hell: Yep, this is rather ugly. :) > libipsec.la: $(libipsec_la_OBJECTS) $(libipsec_la_DEPENDENCIES) > @LD@ -r -o ipsec.o `echo $(libipsec_la_OBJECTS)|sed "s/\.lo/\.o/g"` > `echo $(libipsec_la_LIBADD)|sed "s#lib\([^.]*\)\.la#.libs/lib\1\.a#g"` > 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. And, by the way, the main goal of libtool is to allow portability. :) > Everything would work well - I use libtoolized Makefiles to build > everything, and in one place I build a kernel module - if I could only > make partially linked object from normal objects. See above. > > command line length limits. And for this, libtool also has -objectlist > > as a counter-measure. > > > > Does this help you? > Not yet:) How about now? :) Cheers, Ralf _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
