Call for help: Solaris C++ and Sun CC

[Ralf Wildenhues]

I need some feedback for a Solaris C++ issue (this is the only issue
holding back the 1.5.20 release):

We fixed the failure of
  libtool --mode=link --tag=CXX CC -no-undefined..

with patches from this thread:
http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html
http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html

Now, the addition of `-lCstd -Crun' to the link line will usually cause
libCstd.so.X and libCrun.so.Y to be added to the DT_NEEDED ELF flag.

However, I have encountered a Solaris Workshop 6 update 1 installation
which lacks libCstd.so but not libCstd.so.1.  Thus, the link will take
objects from a static version of libCstd with PIC objects (if I'm not
mistaken), and the created C++ library will contain definitions for STL
symbols.

This is obviously very undesirable, and may lead to huge libraries and
subtle trouble with static state variables only noticed much later and
after much pain.

So I looked around.  I've found this documentation
http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21):

| The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared
| version of the libCstd library.
| To use the shared version of libCstd, do the following:
| 1. As superuser, manually create the following symbolic links.
| 
| example% ln -s /usr/lib/libCstd.so.1 \
|   /opt/SUNWSpro/lib/libCstd.so
| example% ln -s /usr/lib/libCstd.so.1 \
|   /opt/SUNWSpro/lib/v8plus/libCstd.so
| example% ln -s /usr/lib/sparcv9/libCstd.so.1 \
|   /opt/SUNWSpro/lib/v9/libCstd.so
| 
| For the Intel 32-bit processor architecture, you do not need the last
| two links.
| 
| Note -- If your compiler is not installed in the /opt/SUNWSpro
| directory, ask your system administrator for the equivalent path on your
| system.
| 
| 2. Test the links.
| Compile any program with /opt/SUNWSpro/bin/CC, then type the command ldd
| a.out.  The output shows any dependency on /usr/lib/libCstd.so.1.
| 
| Once these symbolic links are created, libCstd is linked dynamically by
| default.
| 
| To link libCstd statically, use the -staticlib-Cstd option.

and this (page 52):
| Sun WorkShop 6 update 1 Compilers C++ (5.2) includes a shared version of
| the libCstd library.
| 
| To use the shared version of libCstd, compile the program in the usual
| way, but use a separate link step.  In the link step, use the
| -library-no%Cstd option, and put the shared library name explicitly on
| the command line, as shown in this example.
| 
| example% CC -library=no%Cstd *.o \
|   -o myprog /opt/SUNWSpro/WS6U1/lib/libCstd.so.1


I don't see a way to have Libtool work correctly in all cases, and I
don't see an easy way to avoid any subtle damage, short of reverting
the patches we've applied, if we are to support older versions of the
compiler, users without root access, and eventual use of
`-staticlib-Cstd'[1].

I'd like any feedback about possible solutions, general ideas about the
issue, or just how *your* Sun CC is set up (with or without these links
etc.).

Thanks,
Ralf

[1] My best bet would be: ignore version 5.1, assume people that want
shared libCstd have set the link, and use the method described for 5.2,
namely: test compile, look at `ldd' output.  But that possibly sucks for
cross-compilation, and requires libtool to use yet another tool.