Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CCAD135.8030901@ece.gatech.edu> Date: Sat, 27 Apr 2002 12:26:29 -0400 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: Danny Smith , binutils , cygwin-apps Subject: Re: Excude whole libs when building w32 dlls with -export-all References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: > Can we detect libs and automatically exclude symbols from shared > libraries? > > i.e. when linking against libcygwin.a, ALL symbols therein are from a > dll, so -by default- should not be exported. Picky point: that's not true in this case. libcygwin.a, unlike most import libs, contains actual code as well as import thunks for cygwin1.dll. > That would remove the need for many default exclusions, and be closer to > unix behaviour (as I understand it). We already exclude symbols beginning with _imp_, and Ralf's patch (well, part of it, IIRC) adds an additional exclusion for symbols beginning with _nm_. And, of course, the data thunks _fu0_ are never re-exported. I dunno if we need something *less* granular (e.g. never never never export ANY symbol of ANY kind that comes from *.dll) ... maybe so. But, this is a separate argument from Danny's proposed patch. Danny is addressing Ralf's long-desired ability to exclude symbols from static convenience libraries that are used by multiple KDE dlls. Without this ability, multiple KDE DLLs have export the same symbols, leading to linking errors when building apps. This has forced Ralf to se a specially hacked binutils for all KDE builds. I like Danny's patch, as it is more flexible than the one Ralf has been using (Ralf's was basically: " --exclude-libs -lfoo -bar --no-exclude-libs -baz" IIRC, so that symbols from libfoo and libbar would not be exported, but symbols from libbaz would be). Ordinarily, at this point, I'd say: "I'll build a binutils and give your patch a try" -- except for the reports that say binutils has been broken on x86 since mid-December. I *really* don't have the time right now to track THAT down, just to test Danny's patch -- I'm in hardcore dissertation mode, right now... --Chuck