V3: Problem on Solaris

[Mark Mitchell]

I now know what is causing the V3 problem on Solaris: static
initializers in libstdc++.so are not being run.

The reason is that we invoke the linker directly (rather than using
`-shared' with gcc/g++) to build the library.  We are therefore
missing crt*.o, and the initializers don't run.

Why are we so silly?  Well, we are invoking libtool, and that's what
libtool wants to do.  Why is libtool so silly?  Well, it's not, really
-- we're lying to it.

In libstdc++-v3/src/Makefile.am we have:

  # 3) We have a problem when building the shared libstdc++ object if
  # the rules automake generates would be used.  We cannot allow CXX to
  # be used in libtool since this would add -lstdc++ to the link line
  # which of course is problematic at this point.
  CXXLINK = $(LIBTOOL) --mode=link "$(CC)" \
	    @OPT_LDFLAGS@ @SECTION_LDFLAGS@ $(AM_CXXFLAGS) $(LDFLAGS) -o $@

Look, we tell libtool to link in *C* mode, rather than *C++* mode.
That fails because in C mode libtool often invokes `ld' directly --
except when using the GNU linker, i.e., on GNU/Linux.(*)

What goes wrong if we add `--tag CXX' to the CXXLINK command?  Well,
we do use -shared, now, but we link in libstdc++, which doesn't exist
yet.

It's hard to say what the right thing is here.  I can't resist quoting
the libtool manual:

  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.

:-)

Since libstdc++ assumes that it is being compiled with G++ already, it
would seem that we could just have used g++ -shared, rather than the
libtool bits, and maybe someday libstdc++ will be compiled with other
compilers.

In any case, we are where we are.  We could have a new libtool tag for
"C++ without stanard libraries".  We could add a means to filter
-lstdc++ out of the libtool `postdeps' variable when we are building
libstdc++ itself.  We can change libtool's C configuration to use gcc
-shared when it knows it is using gcc.  Other options?

I am favoring changing libtool's C configuration to use `gcc -shared'
on Solaris, as it seems like the least trouble, and most clean
approach.  I suspect that maintainers for other non-GNU systems will
want to make similar changes to ltcf-c.sh.

If this works, I'm going to check it in, and switch us to V3.

Alexandre, since you are our libtool expert, do you have insight here?
Does my proposed change sound sensible?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

(*) Many people, myself included, are starting to feel that GCC developers
    are starting to care about GNU/Linux a lot more than about other
    platforms.  It's easy to see why -- a lot of developers work for
    GNU/Linux companies.  A lot of developers *use* GNU/Linux.  And,
    after all, GNU/Linux is the GNU system.

    It's not good, however, to ignore other platforms.  In particular,
    V3 should certainly have been made to work on other platforms long
    before now.  In fact, I just assumed it *did* work on other
    platforms.  That's *my* fault; as RM I should have investigated
    better, and made this happen sooner.