Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3DCDB78F.6050904@ece.gatech.edu> Date: Sat, 09 Nov 2002 20:34:07 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Collins CC: cygwin AT cygwin DOT com Subject: Re: binutils 20021107-2 References: <20021109105904 DOT 24937 DOT qmail AT web21405 DOT mail DOT yahoo DOT com> <1036844910 DOT 31190 DOT 0 DOT camel AT lifelesswks> <3DCD4623 DOT 8070800 AT ece DOT gatech DOT edu> <3DCD4691 DOT 1070601 AT ece DOT gatech DOT edu> <20021109181030 DOT GB16969 AT redhat DOT com> <3DCD520A DOT 6090504 AT ece DOT gatech DOT edu> <3DCD5420 DOT 5000406 AT ece DOT gatech DOT edu> <20021109183512 DOT GA17700 AT redhat DOT com> <3DCD5AE1 DOT 4000708 AT ece DOT gatech DOT edu> <1036885550 DOT 31961 DOT 18 DOT camel AT lifelesswks> Content-Type: multipart/mixed; boundary="------------050704030908050801050706" --------------050704030908050801050706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 --------------050704030908050801050706 Content-Type: text/plain; name="ld_patch_for_gcc2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ld_patch_for_gcc2.diff" Index: pe-dll.c =================================================================== RCS file: /cvs/src/src/ld/pe-dll.c,v retrieving revision 1.45 diff -u -r1.45 pe-dll.c --- pe-dll.c 6 Nov 2002 19:36:20 -0000 1.45 +++ pe-dll.c 10 Nov 2002 01:30:02 -0000 @@ -228,12 +229,14 @@ /* Do not specify library suffix explicitly, to allow for dllized versions. */ static autofilter_entry_type autofilter_liblist[] = { - { "libgcc.", 7 }, - { "libstdc++.", 10 }, - { "libmingw32.", 11 }, - { "libg2c.", 7 }, - { "libsupc++.", 10 }, - { "libobjc.", 8 }, + { "libgcc", 6 }, + { "libstdc++", 9 }, + { "libmingw32", 10 }, + { "libmingwex", 10 }, + { "libg2c", 6 }, + { "libsupc++", 9 }, + { "libobjc", 7 }, + { "libgcj", 6 }, { NULL, 0 } }; --------------050704030908050801050706 Content-Type: text/plain; charset=us-ascii -- 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/ --------------050704030908050801050706--