binutils 20021107-2

[Charles Wilson]

Robert Collins wrote:

>>libmingwex -- maybe.  I dunno -- that's for Danny and/or Earnie to say. 
>>  You really only need library-name based protection for static libs; 
>>symbols in import libs are protected from re-export by symbol-exclude 
>>lists (_nm_*,__imp__*, etc).  libmsvcrt, libmingwthrd -- no (because 
>>they are implibs).
>>
> 
> A light just went on. We could use a "exclude system archive" flag -
> dont' export symbols originating from libraries in /usr/local/lib/* or
> /usr/lib/* ( and possibly the gcc lib dir as well - although I think
> that is a spec thing, as it's gcc's decision to have the library given a
> certain name).
> 
> Whaddya think?


I don't know if we have enough information in the auto_export() context. 
  Here's what I found doing a simple link [ printing 
abfd->my->archive->filename when in auto_export() ].  Each line 
corresponds to a given symbol under consideration for auto-export (not 
shown)

abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a

abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a

abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a
abfd->my_arc->filename=/usr/lib/w32api/libkernel32.a
abfd->my_arc->filename=/usr/lib/w32api/libkernel32.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a
abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a

First, how does ld know about gcc's built in path 
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/ ?.  Second, we'd have to 
canonicalize  /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../ to determine 
if it corresponded to the "system path" /usr/lib/ (which would be a nice 
trick on a cross-compiler setup)

The good news is that almost everything in /usr/lib/w32api/ is an import 
lib, so those symbols are not re-exported anyway...exceptions:

/usr/lib/w32api/libdxguid.a: x86 archive static
/usr/lib/w32api/liblargeint.a: x86 archive static
/usr/lib/w32api/libscrnsave.a: x86 archive static
/usr/lib/w32api/libscrnsavw.a: x86 archive static

So at least we needn't worry overmuch about ../w32api/..

But, I think it's overkill to define "system libs that should not be 
re-exported" as "anything in /usr/lib" or something similarly broad.

Perhaps the "regular" gcc-supplied system libs (libgcc, libstdc++, 
libsupc++, etc) can be explicitly rejected by name from within the 
ld.exe code, but additional **platform** dependent static runtime 
libraries like libmingwex, etc should actually be controlled by the 
platform-specific gcc spec file, using

  --exclude-libs libmingwex.a,libcygwin.a,...

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

On the other hand, we're really arguing about a problem that hasn't bit 
anyone yet.  By excluding the main (gcc) static runtime libs from 
re-export, and the main (platform) static runtime libs like libmingw32 
libmingwex from re-export -- we pretty much cover all the important bases.

Anything else is obviously a corner case, since it hasn't bit anyone yet 
-- and the fix is for that person to specifically exclude the static lib 
that "bit" them by using --exclude-libs.

The problem here, is that because of our packaging of gcc-2, we're 
missing the names of the (gcc) static runtime libs for that "package". 
Plus, libmingwex is another (platform) static runtime lib that we're 
missing -- but it was only recently added to the mingw "platform".

(I raised the issue of libtextmode & friends, but since the only 
"re-exportable" symbol in them is  _cygwin_premain0 which is already 
excluded by autofilter_symbolprefixlist, there's no problem there.)

I think the (newly revised) attached patch is sufficient, and is general 
enough to be submitted for inclusion in the mainline binutils CVS.

--Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ld_patch_for_gcc2.diff
URL: <http://cygwin.com/pipermail/cygwin/attachments/20021109/b8cfb878/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/