Re: makeC++SharedLib_r not used on AIX

[Ralf Wildenhues]

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>