[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
partial linking with non-PIC objects (was: Strange behaviour in libtool-
partial linking with non-PIC objects (was: Strange behaviour in libtool-1.5.20)
Tue, 6 Sep 2005 11:29:12 +0200
* Пухальский Юрий Андреевич 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
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.
> > command line length limits. And for this, libtool also has -objectlist
> > as a counter-measure.
> > Does this help you?
> Not yet:)
How about now? :)