Dave Korn wrote:
> http://sourceware.org/ml/binutils/2008-07/msg00372.html
>
> So I believe now this is a symptom of a buggy ld already fixed upstream.
> I'll try the testcase again against one of my CVS builds of binutils and
> report back, but I expect it will fix the problem and rebase will n
Dave Korn wrote:
> The purpose of playing these games is in order not to drag in the whole
> exception handling machinery into a statically-linked application unless we
> actually need it. We're relying on detecting an unlinked weak symbol by it
> having a value of zero at runtime. That usuall
Corinna Vinschen wrote:
>>
>> Take-home point: never use -static-libgcc when building a DLL.
>
> Baeh. The two of us discussed this in PM a couple of days back and I
> still don't like the idea to depend on cyggcc_s.dll for more or less
> every other package providing a DLL.
Nah, I think I
On Feb 20 15:06, Dave Korn wrote:
> Dave Korn wrote:
> Ah. Right. Ouch. I see what's going on. Rebasing does not interact well
> with the presence of unresolved weaks. Gah.
> [...]
> I'll need to do some thinking about this, as it might be possible to make it
> work, but in any case, the r
Dave Korn wrote:
> Ok, now I'll try debugging it.
Ah. Right. Ouch. I see what's going on. Rebasing does not interact well
with the presence of unresolved weaks. Gah.
The problem arises here, in cygming-crtbegin.c:
--
extern void __register_
On Feb 20 14:14, Dave Korn wrote:
> Dave Korn wrote:
> > Corinna Vinschen wrote:
>
> >> Apparently. I rebased the DLL alone and afterwards file simply stopped
> >> working. The DLL has a base address of 0x6a50. Even rebasing to
> >> the very same address results in a coredump!
>
> > Nope
Dave Korn wrote:
> Corinna Vinschen wrote:
>> Apparently. I rebased the DLL alone and afterwards file simply stopped
>> working. The DLL has a base address of 0x6a50. Even rebasing to
>> the very same address results in a coredump!
> Nope, I can't reproduce it yet.
I can now, but no
On Feb 20 14:45, Corinna Vinschen wrote:
> On Feb 20 13:35, Dave Korn wrote:
> > magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from
> > integer without a cast
> >
> >304 (void)strlcat(strlcpy(tmp, inname,
> > len), ".exe", len);
> >
> >
> >
On Feb 20 13:35, Dave Korn wrote:
> Corinna Vinschen wrote:
> > Apparently. I rebased the DLL alone and afterwards file simply stopped
> > working. The DLL has a base address of 0x6a50. Even rebasing to
> > the very same address results in a coredump!
> >
> > The DLL has been built with -st
Corinna Vinschen wrote:
>> I haven't rebased again, but is there any reason to suspect that
>> cygmagic-1.dll is not rebaseable?
>
> Apparently. I rebased the DLL alone and afterwards file simply stopped
> working. The DLL has a base address of 0x6a50. Even rebasing to
> the very same addres
Corinna Vinschen wrote:
> On Feb 19 23:03, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> I've updated the Cygwin 1.7 version of file to 5.00-1.
>> Odd behavior: after I did a rebaseall, I was consistently seeing
>> coredumps using this version of file. Reverting to the older version of
>> f
On Feb 19 23:03, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > I've updated the Cygwin 1.7 version of file to 5.00-1.
>
> Odd behavior: after I did a rebaseall, I was consistently seeing
> coredumps using this version of file. Reverting to the older version of
> file fixed it, as did re-ins
Corinna Vinschen wrote:
> I've updated the Cygwin 1.7 version of file to 5.00-1.
Odd behavior: after I did a rebaseall, I was consistently seeing
coredumps using this version of file. Reverting to the older version of
file fixed it, as did re-installing the new version.
I haven't rebased again,
I've updated the Cygwin 1.7 version of file to 5.00-1.
This is an update to the latest official upstream version 5.00.
The Cygwin version is build from the vanilla sources with the
latest libtool applied and a minor change in an error message.
Both changes have been send upstream.
To update your
14 matches
Mail list logo
