Robert Collins wrote:
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.
Why? *anything* in /usr/lib is able to be linked to from multiple
packages. If one package creates a dll from there, then we will ge
On Saturday 09 November 2002 15:45, Robert Collins wrote:
> On Sun, 2002-11-10 at 05:58, Charles Wilson wrote:
> > Christopher Faylor wrote:
> > > Shouldn't there be a few more entries in this list, like libmingwex,
> > > libmingwthrd, libmsvcrt (maybe). I don't know if any of those
> > > librarie
On Sun, 2002-11-10 at 12:34, Charles Wilson wrote:
> 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 considera
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
On Sun, 2002-11-10 at 05:58, Charles Wilson wrote:
> Christopher Faylor wrote:
>
>
> > Shouldn't there be a few more entries in this list, like libmingwex,
> > libmingwthrd, libmsvcrt (maybe). I don't know if any of those libraries
> > have globals that could be erroneously exported but doesn't
Christopher Faylor wrote:
Shouldn't there be a few more entries in this list, like libmingwex,
libmingwthrd, libmsvcrt (maybe). I don't know if any of those libraries
have globals that could be erroneously exported but doesn't it pay to
be safe?
libmingwex -- maybe. I dunno -- that's for Da
On Sat, Nov 09, 2002 at 01:29:52PM -0500, Charles Wilson wrote:
>Charles Wilson wrote:
Oops. Previous patch still left a chunk of Egor's changes. New
patch replaces.
>>>
>>>How about submitting the patch to the binutils mailing list?
>>>
>>
>>
>>I've no objections -- but the patch i
Charles Wilson wrote:
Oops. Previous patch still left a chunk of Egor's changes. New
patch replaces.
How about submitting the patch to the binutils mailing list?
I've no objections -- but the patch is a workaround for a
cygwin-specific packaging decision (e.g. providing gcc-2.95.3 as "
Christopher Faylor wrote:
Nope. Chris should apply the attached patch to binutils and re-release.
It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were
getting their shakedown this summer. Oh well.
Also, Chris, you could take the opportunity of binutils-20021107-3 to
apply Ego
On Sat, Nov 09, 2002 at 12:32:01PM -0500, Charles Wilson wrote:
>Charles Wilson wrote:
>
>
>>Nope. Chris should apply the attached patch to binutils and re-release.
>> It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were
>>getting their shakedown this summer. Oh well.
>>
>>Also, Chr
Charles Wilson wrote:
Nope. Chris should apply the attached patch to binutils and re-release.
It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were
getting their shakedown this summer. Oh well.
Also, Chris, you could take the opportunity of binutils-20021107-3 to
apply Egor's r
Robert Collins wrote:
On Sat, 2002-11-09 at 21:59, Danny Smith wrote:
Hello Robert
By default symbols in libstdc++.a are excluded when doing --export-all, to
protect against this type of error.
However, ld/pe-dll.c knows nothing about libstdc++-2.a. So those symbols do
get exported ... and c
On Sat, 2002-11-09 at 21:59, Danny Smith wrote:
> Hello Robert
>
> By default symbols in libstdc++.a are excluded when doing --export-all, to
> protect against this type of error.
>
> However, ld/pe-dll.c knows nothing about libstdc++-2.a. So those symbols do
> get exported ... and cause the usu
Hello Robert
By default symbols in libstdc++.a are excluded when doing --export-all, to
protect against this type of error.
However, ld/pe-dll.c knows nothing about libstdc++-2.a. So those symbols do
get exported ... and cause the usual problems with multiple definitions.
Quick solution: Try --
14 matches
Mail list logo