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

[Ralf Wildenhues]

* Пухальский Юрий Андреевич 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