Re: libtool convenience libraries and C++ constructors (fwd)

[Tim Janik]

On Thu, 9 Mar 2006, Ralf Wildenhues wrote:

> Hi Tim,
>
> * Tim Janik wrote on Wed, Mar 08, 2006 at 10:17:22PM CET:
> > looks to me (from peeking at the libtool mailing list), that you're
> > one of the new maintainers now.
>
> Yes, that is true.
>
> > i'm looking into getting libtool convenience libraries to work
> > with C++ constructors (using 1.5.6 currently), is there any information
> > about this you could point me at?
>
> Hmm.  We've done some work for better template support in the CVS
> version.  What's the issue with constructors, initialization order or
> are there more issues?  A problematic example would be useful to test.
> Which system and compiler are you using?

hm, when i wrote this, i was already suspecting that you simply don't
support C++ convenience libraries at all. it's probably best if i
just give a run down of my problems and current solutions bit-by-bit:

- i'm running linux 2.6.* on top of debian stable (glibc-2.3.2) with g++-3.4
- i'm using automake-1.4
- i'm using libtool-1.5.6 from debian stable (i think that's a bit
  patched here and there, but in code portions unrelated to my
  problems at hand)
- for the beast project (http://beast.gtk.org, sources are in GNOME CVS),
  i want the following source tree layout:
  beast/birnet/ build convenience archive libbirnet.la from C and C++ sources
  beast/sfi/    build convenience archive libsfi.la from C and C++ sources
  beast/bse/ build installable shared library libbse.la from C sources,
             C++ sources and libbirnet.la and libsfi.la
  i.e. the plan is to have all symbols provided by libbirnet.la, libsfi.la
  and libbse.la, be available on the system through /usr/local/lib/libbse.so.
- to restrict symbol visibility, i'm using:
    -Wl,--version-script=$(srcdir)/ldscript.map
  to link libbse.la, ldscript.map currently simply forbids exporting of all
  dynamic symbols except ones from the bse*, sfi* and birnet* namespaces.
  details about the whys and hows can be found in:
    http://people.redhat.com/drepper/dsohowto.pdf
- my first attempt was to use:
    birnet/Makefile.am:noinst_LTLIBRARY = libbirnet.la
    sfi/Makefile.am:noinst_LTLIBRARY = libsfi.la
    bse/Makefile.am:lib_LTLIBRARIES = libbse.la
    bse/Makefile.am:libbse_la_LIBADD = ../birnet/libbirnet.la ../sfi/libsfi.la
  this even works for only-C sources, or for C++ sources without static
  constructors. because "ar" is used however, if static C++ constructors
  are being added to multiple C++ files, only the constructors of *one*
  object file will be executed before main(), the rest is simply forgotten
  about.
- from reading about, i figured i had to essentially use "ld -r" to partially
  link C++ sources (and "ld -Ur" or the compiler for the final stage). then
  i read some more (libtool sources) to figure how to get libtool to use "ld 
-r"
  instead of ar. turns out that libtool already does this when libraries are
  built as .lo or .o files. unfortunately, automake pukes at lt-library names
  that don't end in .la ;(
  otherwise i could have s/.la/.lo/ for the above noinst_LTLIBRARY entries
  and be done.
- so what i'm currently using is basically:
    birnet/Makefile.am:
        # Birnet library
	# we want a partial shared library here. libtool creates that if the 
library
	# name ends in .lo or .o. however automake doesn't know .lo or .o 
libraries,
	# so we simply build an ordinary non-installed .la library and then use 
our
        # own rule to build the .o from the .la pieces.
        noinst_LTLIBRARIES         = libbirnet.la
        [...]
	# keep this .o rule in sync with the corresponding .la rule from 
Makefile.in
        libbirnet.o: $(libbirnet_la_OBJECTS) $(libbirnet_la_DEPENDENCIES)
		$(CXXLINK)  $(libbirnet_la_LDFLAGS) $(libbirnet_la_OBJECTS) # 
$(libbirnet_la_LIBADD) $(LIBS)
        all-am: libbirnet.o
        CLEANFILES += libbirnet.lo libbirnet.o
  and the same for afi/Makefile.am. that way, i can link libbse.la as:
        lib_LTLIBRARIES       = libbse.la
        libbse_la_LIBADD      = ../birnet/libbirnet.o ../sfi/libsfi.o
  which triggers some libtool portability warning but seems to work.
- i'm not using .lo for the partial library names above, because while
  libtool will build .lo libraries correctly (similar to how it builds
  .o in the above), the actual binary code ends up in the .lo file.
  and the .lo file will libtool later refuse to link into another library,
  because the .lo file it just created "is not a valid libtool archive"
  (i.e. no shell script wrapper). that's, allthough libtool in fact
  created the file itself... ;)

let me know if you need any more info, or if there are better ways to achieve
what i need and thanks for your response.

> Cheers,
> Ralf

---
ciaoTJ