This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Crash sourcing Python script on Windows


> Date: Wed, 28 Sep 2011 21:06:34 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> It could be something simpler than that. Python was built on one
> system, using an unknown build environment. when then use that
> library to link it against some code on a version of Windows that
> is most likely different, with a compiler that is also most likely
> different. If each compiler used a libc where the definition of
> that type is different, then we have an incompatibility.

That's true, but just looking at the definitions of the FILE object in
both MS and MinGW headers, I can't see any differences.  Which is
quite expected: if it were not so, MinGW programs couldn't call APIs
that accept FILE objects, like `fopen', since the implementation of
`fopen' is in the Microsoft runtime DLLs, which was compiled by the
Microsoft compiler, the same one used to build Python DLLs for
Windows.

So it would be good to know the details of what led you to the
conclusion that the FILE object was incompatible between GDB and
Python DLL.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]