[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tim Janik
Subject: Re: libtool convenience libraries and C++ constructors (fwd)
Date: Thu, 9 Mar 2006 16:30:10 +0100 (CET)

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 (, sources are in GNOME CVS),
  i want the following source tree layout:
  beast/birnet/ build convenience archive from C and C++ sources
  beast/sfi/    build convenience archive from C and C++ sources
  beast/bse/ build installable shared library from C sources,
             C++ sources and and
  i.e. the plan is to have all symbols provided by,
  and, be available on the system through /usr/local/lib/
- to restrict symbol visibility, i'm using:
  to link, 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:
- my first attempt was to use:
    birnet/ =
    sfi/ =
    bse/ =
    bse/ = ../birnet/ ../sfi/
  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
- 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 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         =
# keep this .o rule in sync with the corresponding .la rule from
        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/ that way, i can link as:
        lib_LTLIBRARIES       =
        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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]