On Mon, Mar 23, 2009 at 3:23 PM, Christopher Faylor
> On Sat, Mar 21, 2009 at 07:32:03PM +0100, Kai Tietz wrote:
>>Not me. AFAIK NightStrike just mentioned that for 4.3 the issue didn't
>>happened. I assume it is poped up by using shared libgcc, because here
>>the symbol get in conflict with the exports of kernel32.dll and
>>ntdll.dll (we provided in our runtime). So the bug was already
>>present, but it's present just showed up in 4.4.
>>Just by this reason NightStrike sees this as regression and I can't
>>say that this is wrong from an user point of view. It seems to me that
>>this is a bug with a long history.
>>For me it is not urgent, but we have to life with that hack in our crt
>>for the long time of 4.4 and we come to same catch 22 situation I
>>would like to avoid. so I would like to see it 4.4. And it fixes a
>>latent bug also for 32-bit win32 targets, present now for a long time.
> I guess I have no objections to this being included if Danny agrees
> to withdraw his objection.
I have no strong objections, but I would really like to understand why
this patch is so urgent.
libgcc exports "__chkstk" (prefixed with an additional underscore in assembler)
ntdll.dll exports "_chkstk" (prefixed with an additional underscore
ntdll.dll is not part of the documented userland win32api. To my
knowledge, it is not included in the Platform SDK.
I do not know how you created or use the import lib for ntdll.dll
On my Windows XP system kernel32.dll exports neither __chkstk nor _chkstk
How does the ntdll.dll export of "_chkstk" cause you problems in 4.4
but not in 4.3.
WTF has changed.