Re: Cygwin List O' Issues...[static runtime libs]

[Charles Wilson]

> 1. C++ (actually, all tags except C) is broken.  This is because 

> the non-C tags extract the list of runtime stdlibs from the

> compiler, and then explicitly add them to the link command (while 
> using -nostdlibs).  This has the effect of requiring that the

> runtime libs satisfy the "is it dynamic?" check in $file_magic_cmd.
>
> Since the cygwin gcc/g++/g77 compiler suite provides only static 

> versions of libgcc, libstdc++, libsupc++, libg2c, etc, this means

> that ALL shared libs written in those languages fail to build.  

> (Strangely, the C tag does NOT behave this way.  Inconsistency...)  

> But the lack of a shared version of the runtime libs should NOT 

> preclude building DLLs on windows -- and in fact, it probably shouldn't

> preclude them on Linux or Solaris, either (shared libs containing 
> non-PIC runtime code just runs a little slower, that's all).
>
> This bug can also affect other platforms (but most platforms' compiler

> suite supply shared versions of the runtime libs, so the behavior is not 

> as visible).

The attached example is 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 (in tag C).  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.

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 the example, you need a recent version of autoconf and automake. 
 Also, you need a recent CVS version of libtool.  Unpack the archive, and
 ./bootstrap
 ./configure --prefix=/usr
 make

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

To completely clean up, use
 ./unbootstrap

My (partial) results:
--------------------------------------------------
/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)

runtime-libs-demo.tar.bz2
Description: Binary data