[Metakit] libtool

[Jean-Claude Wippler]

I have a question...

For some reason I do not quite understand, MK builds shared libs with "ld". This completes and works as expected with C++ programs, but it causes runtime errors when loaded from a C main (for example Mk4tcl.so loaded from tclsh). It may also breaks down even with C++ in Unix systems which do not support shared library back-linking.

The libtool 1.4.1 info docs sound ominous:

Writing libraries for C++
=========================

Creating libraries of C++ code should be a fairly straightforward
process, because its object files differ from C ones in only three ways:

1. Because of name mangling, C++ libraries are only usable by the C++
compiler that created them. This decision was made by the
designers of C++ in order to protect users from conflicting
implementations of features such as constructors, exception
handling, and RTTI.

2. On some systems, the C++ compiler must take special actions for the
dynamic linker to run dynamic (i.e., run-time) initializers. This
means that we should not call `ld' directly to link such
libraries, and we should use the C++ compiler instead.

3. C++ compilers will link some Standard C++ library in by default,
but libtool does not know which are these libraries, so it cannot
even run the inter-library dependence analyzer to check how to
link it in. Therefore, running `ld' to link a C++ program or
library is deemed to fail. However, running the C++ compiler
directly may lead to problems related with inter-library
dependencies.

The conclusion is that libtool is not ready for general use for C++
libraries. You should avoid any global or static variable
initializations that would cause an "initializer element is not
constant" error if you compiled them with a standard C compiler.

There are other ways of working around this problem, but they are
beyond the scope of this manual.

Furthermore, you'd better find out, at configure time, what are the
C++ Standard libraries that the C++ compiler will link in by default,
and explicitly list them in the link command line. Hopefully, in the
future, libtool will be able to do this job by itself.



My question is: would anyone have a suggestion how to deal with this in the most portable manner? I tend to use MK mostly in static-linked form, but evidently it would be nice to make this work in the most general way possible. The current CVS sources have a "-lstdc++" added to LDFLAGS, which solves it for Linux, but generate the following output on MacOS X (both are gcc 3.1/3.2):

*** Warning: This library needs some functionality provided by -lstdc++.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
g++ -dynamiclib -flat_namespace -undefined suppress -o .libs/libmk4tcl.dylib mk4tcl.lo mk4too.lo column.lo custom.lo derived.lo fileio.lo field.lo format.lo handler.lo persist.lo remap.lo std.lo store.lo string.lo table.lo univ.lo view.lo viewx.lo -lc -install_name /usr/local/lib/libmk4tcl.dylib

The resulting library does load in tclsh.

Should the conclusion be to throw out libtool altogether? Frankly, I wouldn't mind one bit...

-jcw

_______________________________________________
metakit mailing list - [EMAIL PROTECTED]
http://www.equi4.com/mailman/listinfo/metakit