Based on libtool's tagdemo test.

Demonstrates the severe brokenness of C++ support, at least
on cygwin.  The problem is, libtool treats C++ and the other
tags differently than C.

In C, only explicitly listed dependent libraries are tested 
for 'sharedness'.  If any are static, then libtool will 
refuse to create a shared lib that depends on them.  However,
this does NOT include the 'stdlib' libgcc.  If libgcc.a is
static (and there is no shared version) -- libtool doesn't 
care.  It creates the sharedlib anyway.

In C++, libtool uses -nostdlib in the link command.  It
(somehow) gets a list of the libs that WOULD be added by 
g++ if nostdlib were NOT used, and explicitly adds those 
libs to the link command.  Then, the $file_magic_cmd is used
to determine if they are all shared.  If not, the link "fails"
and libtool falls back to building a static lib.  I assume the
other tags behave like C++.

I think the behavior, with respect to the runtime libs, should
be like C, not C++.  (I'm a bit biased; on cygwin, except for
the cygwin kernel itself, all of our gcc-provided runtime 
libs are available as static libs only.  The C++ behavior 
means that we cannot have ANY C++ shared libs.

I hesitate to mention it, but the current behavior is asymetric.
Either ALL tags should extract the stdlibs, use -nostdlib, and 
add the stdlibs explicitly to the link line -- and check
their 'sharedness' via $file_magic_cmd -- or NONE should. This
inconsistent behavior is bad.

Of course, consistently checking the runtime libs (incl. libgcc) 
in all tags would make libtool unusable on cygwin.

I really think that "The Right Thing" is the following:

1) create a new "official" libtool variable (like max_cmd_len) 
that appears in every tag.  "check_for_runtime_shlibs".  Defaults 
to "no". "yes" is current behavior (mostly -- see 3).

2) If "no", then avoid -nostdlibs. Behave like the current C tag.  
This way, static runtimes are ok, even if building a sharedlib. 
cygwin/windows would set this "no".  Maybe linux/solaries.  I dunno.

3) If "yes", then all tags should behave like C++ does now 
(*including* the C tag).  Figure out the name of the runtime libs 
for this tag (GNU C++: libgcc libstdc++ libsupc++.  GNU F77: libg2c.  
etc).  Use -nostdlibs, but explicitly add the libs back to the 
command line, and let the "file_magic_cmd" take over.

But I don't have any clue how to implement this...

--------------------------------------

To run, unpack, and
 ./bootstrap
 ./configure --prefix=/usr
 make

You'll see that the build fails (on cygwin, since standard 
linux and solaris installations HAVE shared versions of their
runtime libs).

To completely clean up, use
 ./unbootstrap


/bin/bash ./libtool --mode=link g++  -g -O2   -o libfoo.la -rpath /usr/lib -version-info 1:0:1 -no-undefined foo.lo  

*** Warning: linker path does not have real file for library -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
*** because I did check the linker path looking for a file starting
*** with libstdc++ and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/libstdc++.a.2.10.0

*** Warning: linker path does not have real file for library -lgcc.
*** 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
*** because I did check the linker path looking for a file starting
*** with libgcc and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libgcc.a

*** Warning: linker path does not have real file for library -lgcc.
*** 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
*** because I did check the linker path looking for a file starting
*** with libgcc and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libgcc.a
*** 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.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
ar cru .libs/libfoo.a  foo.o
ranlib .libs/libfoo.a
creating libfoo.la
(cd .libs && rm -f libfoo.la && ln -s ../libfoo.la libfoo.la)

