Re: Partial linking with _RELOCATABLES - Proposed enhancement

[Alexandre Duret-Lutz]

(I haven't read the patch yet.)

>>> "MA" == Marc Alff <address@hidden> writes:

[...]

 MA> A typical "partial link" or "relocatable (-r)"  command is :
 MA> ld -r -o glued.o part1.o part2.o ... partn.o

I didn't know "ld -r".  How portable is it?

 MA> As a result, a build chain can be longer :

 MA> *.c, *.cpp --> *.o --> * glued.o --> * super-glued.o --> lib*.a, lib*.so 
 MA> or binaries

Will your proposal allow the creation of *.a, *.so, and
binaries out of relocatable objects?  I'm wondering, because the
*.o should be compiled differently if they are meant to be part
of a shared library, and the _RELOCATABLES syntax doesn't
indicate where the object will be used.

 MA> The difference between "glued.o" and "libglued.a" is that a 
 MA> "relocatable" object
 MA> contains all the code in one block, with internal link dependencies 
 MA> already resolved,

Just to make sure I understand: would I get a similar result if
instead of gluing these objects I had compiled the concatenation
of all their sources in a single run of the compiler?

(Consider that question from the point of view of someone who is
used to split static libraries in as much objects as possible so
the linker picks only what it needs and not more.)

[...]

 MA> The main concern is that, how the source code is organized into directories
 MA> with recursive makefiles is an implementation choice,
 MA> it should **not** impact what the final deliverable looks like (maybe I 
 MA> still want ONE *.a or *.so or binary at the end,
 MA> not expose a collection of *.a or *.so to my users).

Of your three points, this is the only one I do not understand.
If you use Libtool convenience libraries you'll have a
collection of *.la in your build tree for all the subparts of
your project, but then you'll gather all these in a big *.la
library which you will install.  So the final deliverable is
still one library, not a collection of libraries.
(Example in the "Libtool Convenience Libraries" section of the
Automake manual.)

 MA> ============ Part III : Proposed enhancement ============

 MA> In short, Makefile.am can be written like this

 MA> noinst_RELOCATABLES = glued.o
 MA> glued_o_SOURCES = part-1.cpp part-2.cpp

 MA> glued.o is a **notation**, not the actual name of a file :

 MA> ..._RELOCATABLES = glued.o super-glued.obj
 MA> glued_o_... = ...
 MA> super-glued_obj_... = ...

s/-/_/

 MA> will work both on platforms that use .o or .obj for objects,
 MA> and in both cases the generated makefile will contain names like :
 MA> glued.$(OBJEXT) : ...
 MA> super-glued.$(OBJEXT) : ...

Allowing both extensions in _RELOCATABLES (and hence in the
associated variable names) looks confusing to me.  In any way
the resulting objects may not be built as written, so the
extension we write here is just a convention.  I'd say let's
offer only syntax.

 MA> You can add these if you like :
 MA> glued_o_LDR = /my/own/ldr/program
 MA> glued_o_LDRFLAGS = -please -make -section blah -start -at -address blah
 MA> glued_o_LIBADD = more-part-X.$(OBJEXT) more-part-Y.$(OBJEXT)

(Independently of your patch I'm wondering if Automake should not try
to replace .o by .$(OBJEXT) in LDADD/LIBADD lines.)

 MA> The generated Makefile uses LIBTOOL to actually do the linking work,
 MA> so it should be portable : $LIBTOOL --mode=link xxx

Where xxx is "ld -r ..."?  I'd like to hear from the Libtool
folks about this.  Is libtool supposed to emulate "ld -r" or
something if it doesn't work?

My intuition is that if libtool knows how perform "ld -r"
portably then there is an easier way to go:
  - libtool's convenience libraries can be used to setup the
    kind of hierarchical layout you described, and they can be
    used to build static or shared libraries as well as when
    linking program
  - so I guess all you need is a libtool switch to ask
    for a relocatable output.  

Then you'd write something like

  noinst_LTLIBRARIES = libpart.la
  libpart_la_SOURCES = foo.c bar.c
  libpart_la_LDFLAGS = -reloadable
  bin_PROGRAMS = whatever
  whatever_SOURCES = main.c
  whatever_LDADD = libpart.la

Does it make any sense?
-- 
Alexandre Duret-Lutz

Shared books are happy books.     http://www.bookcrossing.com/friend/gadl