Hello Tommi, Thanks for the report and the test case, and apologies for the delay.
* Tommi Mäkitalo wrote on Fri, Dec 22, 2006 at 04:25:30PM CET: > > for building a C++-library on AIX there is a script makeC++SharedLib or > makeC++SharedLib_r in multithreaded apps, which according to IBM have to be > used. Otherwise static initializers are not called. Yes, I see this. It seems they use some asm hackery for reliable initialization order. This is definitely something libtool shouldn't try to do itself. But one problem with using one of makeC++SharedLib* is exactly that choice: how would libtool choose the right one? On an AIX systems I have access to, the script can have suffixes _r _r4 _r7 _128 (thread safe, thread safe with some compatibility library, 128 bit long double; default is not thread safe), according to which some library paths are added and libraries linked against. Anyway, the manual documents that xlC -qmkshrobj[=PRIO] should be used instead. So I experimented with that. It seems to help but I don't think that we can automatically fix things for users that actually need a certain initialization order. There are several ways[1] to set the relative initialization priority order, for users that need this. > I ran into this problem and prepared a testcase, which confirms this. I > modified the tagdemo to use a static std::string-object to print the in the > library. On AIX the string is empty. > > You can find my modified version of tagdemo on > http://www.tntnet.org/tagdemo-0.1.tar.gz and the output on AIX at > http://www.tntnet.org/tagdemo.out. > > There is a empty line instead of the message "** This is libfoo (tagdemo) **" > in the output. I can get the testcase to work - without runtimelinking: by adding -qmkshrobj to the link flags of libfoo.la: make libfoo_la_LDFLAGS='-no-undefined -qmkshrobj' - with runtimelinking: configure LDFLAGS=-Wl,-brtl (this is needed at configure time because libtool makes some decisions based on this flag) So first, runtimelinking is a suitable workaround. Second, we should think about adding the -qmkshrobj flag if xlC supports it. Not sure yet what other semantic changes it will cause. Disclaimer: all my testing has been done with CVS HEAD Libtool only so far. Cheers, Ralf [1] <http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/proguide/ref/tushrlib.htm> _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool