This is the mail archive of the
mailing list for the binutils project.
Re: Excude whole libs when building w32 dlls with -export-all
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Robert Collins <robert dot collins at itdomain dot com dot au>
- Cc: Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>,binutils <binutils at sources dot redhat dot com>,cygwin-apps <cygwin-apps at cygwin dot com>
- Date: Sat, 27 Apr 2002 12:26:29 -0400
- Subject: Re: Excude whole libs when building w32 dlls with -export-all
- References: <FC169E059D1A0442A04C40F86D9BA7600C5F2E@itdomain003.itdomain.net.au>
Robert Collins wrote:
> Can we detect libs and automatically exclude symbols from shared
> 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...