Paul Moore wrote:
OK, I've got a copy of the Python sources, and had a look. The change
needed to msi.py to include libpythonXX.a in the installer looks
simple. But I'm less sure as to where to build the file. It seems to
me that msi.py is not the right place - that's focused on building the
instal
On Wed, 15 Dec 2004 22:57:00 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > For a starter, what steps do you actually take to build a release? I
> > assume that the first step is to build Python, by clicking on "build"
> > in VS.NET.
>
> Yes. You can skip this step by ju
Paul Moore wrote:
For a starter, what steps do you actually take to build a release? I
assume that the first step is to build Python, by clicking on "build"
in VS.NET.
Yes. You can skip this step by just putting all the .pyds, dlls, and
.exes into the PCbuild directory. The packaging will try to p
On Tue, 14 Dec 2004 23:48:41 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I understand that one still needs to build libpython24.a in order to
> use this process. As I have said, I'd happily ship that file with the
> 2.4.1 MSI, unless the release manager tells me that this would an
> unaccep
"Martin v. Löwis" wrote:
> Not at all. I'm talking about the release process, and prerequisites
> required in that process. This is worth mentioning because the list
> of prerequisites you need to perform a Python release is already quite
> long:
Ah - sorry - misinterpreted.
What is the size of
"Martin v. Löwis" wrote:
> Paul Moore wrote:
>> Thanks for your comments. Your support for the viability of building
>> extensions using mingw is important to me, so if you still have any
>> concerns, let me know and I will do my best to address them.
>
> I understand that one still needs to buil
Delaney, Timothy C (Timothy) wrote:
it is ok to assume that a cygwin installation is in c:\cygwin.
I think we should aim to support MSYS as well as Cygwin, but perhaps
not for the first version where this goes in.
Not at all. I'm talking about the release process, and prerequisites
required in tha
Paul Moore wrote:
Thanks for your comments. Your support for the viability of building
extensions using mingw is important to me, so if you still have any
concerns, let me know and I will do my best to address them.
I understand that one still needs to build libpython24.a in order to
use this proce
Paul Moore wrote:
My current technique for checking an extension is compatible with
Python 2.4 is to run objdump -p (from the mingw distribution - use
dumpbin /imports from MSVC) and review the import table. If any
symbols are referenced from msvcrt.dll, you need to convince yourself
that they are
Thomas Heller wrote:
And recently I played with bindings to OpenGL's glut32.dll - glut calls
exit() from internal C code. If linked with the wrong CRT, this will do
nothing instead of terminating the process.
Interesting. Looking at the code of exit(), it is clear that the wrong
atexit handlers wi
On Mon, 13 Dec 2004 23:17:51 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I forgot the details of your analysis, but I think you are right.
> However, I would feel more comfortable if only a single CRT was used
> from an extension module.
Agreed. But to some extent I'm equally uncomfortable
On Mon, 13 Dec 2004 16:43:18 +, A.B., Khalid <[EMAIL PROTECTED]> wrote:
> So what see ye? :) Does it look good?
Looks good to me. The one remaining link to msvcrt, abort, is likely
to be due to the startup code using it, and your code not referencing
that symbol, so that it doesn't force linki
Paul Moore <[EMAIL PROTECTED]> writes:
> The biggest problem with CRT compatibility issues is that (AFAIK)
> no-one has actually been able to trigger a *real* error, all of the
> problems are still theoretical.
There have been problems with the bdist_wininst exe-stub linking to the
wrong CRT dll,
On Sun, 12 Dec 2004 23:19:55 +, A.B., Khalid <[EMAIL PROTECTED]> wrote:
> [2] Can someone who has the official Python 2.4 download the sample
> extension [**] created using the pyMinGW patched & MinGW compiled Python 2.4
> and SWIG? And see if it works?
> Sources are in the zip file whose
At 11:07 PM 12/12/04 +0100, Martin v. Löwis wrote:
it is not that
clear whether extensions build with mingw will work in the standard
2.4 distribution, or whether you can use the standard 2.4 distribution
to build extensions with mingw.
I thought that it was clarified some time ago, with my success
A.B., Khalid wrote:
I am following this thread with interest too, because I can certainly
report that it is now indeed possible and quite easy to compile not only
Python's 2.4 extensions but also Python itself in MinGW with the help of
pyMinGW[1]. Indeed there is no need to buy or even download
16 matches
Mail list logo
