[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cygwin List O' Issus (take 2): #1 static runtime libs
From: |
Charles Wilson |
Subject: |
Cygwin List O' Issus (take 2): #1 static runtime libs |
Date: |
Fri, 01 Nov 2002 15:01:09 -0500 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 |
Restating the remaining issues since (a) it's a new month for the
mailman archiver (b) some issues have been resolved (yay!)
> 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
- Cygwin List O' Issus (take 2): #1 static runtime libs,
Charles Wilson <=