From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: maillist-gdbpatches@barfooze.de, gdb-patches@sourceware.org
Subject: Re: [RFC] Crash sourcing Python script on Windows
Date: Thu, 29 Sep 2011 07:30:00 -0000 [thread overview]
Message-ID: <83ty7verow.fsf@gnu.org> (raw)
In-Reply-To: <20110929040634.GD19246@adacore.com>
> 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.
next prev parent reply other threads:[~2011-09-29 7:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 23:24 Joel Brobecker
2011-09-29 2:00 ` Paul_Koning
2011-09-29 2:19 ` John Spencer
2011-09-29 4:47 ` Joel Brobecker
2011-09-29 7:30 ` Eli Zaretskii [this message]
2011-09-29 8:54 ` Kai Tietz
2011-09-29 9:48 ` Eli Zaretskii
2011-09-29 9:51 ` Kai Tietz
2011-09-29 10:54 ` Pedro Alves
2011-09-29 12:33 ` Eli Zaretskii
2011-09-29 12:48 ` Kai Tietz
2011-09-29 13:19 ` Pedro Alves
2011-09-29 7:26 ` Eli Zaretskii
2011-10-03 20:05 ` Tom Tromey
2011-09-29 7:20 ` Eli Zaretskii
2011-10-03 20:02 ` Tom Tromey
2011-10-03 20:53 ` Joel Brobecker
2011-10-04 17:08 ` Tom Tromey
2012-01-23 18:14 ` [patch] Do not open Python scripts twice #2 [Re: [RFC] Crash sourcing Python script on Windows] Jan Kratochvil
2012-01-23 18:41 ` Pedro Alves
2012-01-23 21:55 ` Jan Kratochvil
2012-01-23 22:08 ` Doug Evans
2012-01-23 22:47 ` Jan Kratochvil
2012-01-23 23:47 ` Doug Evans
2012-01-24 14:45 ` Jan Kratochvil
2012-01-24 18:56 ` Doug Evans
2012-01-24 19:41 ` Jan Kratochvil
2012-01-24 22:20 ` Doug Evans
2012-01-24 23:49 ` Jan Kratochvil
2012-01-25 22:30 ` Jan Kratochvil
2012-01-26 7:18 ` Joel Brobecker
2012-01-26 22:03 ` [commit] " Jan Kratochvil
2012-01-24 15:15 ` Pedro Alves
2012-01-23 19:57 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ty7verow.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=maillist-gdbpatches@barfooze.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox