[issue10504] Trivial mingw compile fixes

[Irit Katriel]

Change by Irit Katriel :


--
resolution: duplicate -> wont fix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> MinGW is unsupported - close all open issues and list them here.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Martin Panter]

Martin Panter added the comment:

The patch seems to share some changes to Modules/posixmodule.c with parts of 
Issue 17598’s patch (and one common part has already been applied).

Issue 17591 already fixed  to lowercase.

Just now Issue 28269 has been opened about strcasecmp().

--
dependencies: +[MinGW] Can't compile Python/dynload_win.c due to static 
strcasecmp, mingw: init system calls, mingw: use header in lowercase
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Kalev Lember]

Changes by Kalev Lember :


--
nosy: +kalev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Ralf Schmitt]

Changes by Ralf Schmitt :


--
nosy: +schmir

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

But a "strict bugfix" should fix something.  Is there something that did not 
work before, and will work after this patch? IOW, how do you compile 
posixmodule.c with MinGW and does it produce a working module?

Now, I *am* interested in a working MinGW build.  Please share what you have 
done.  Your patch will certainly be merged into the py3k branch.
But it won't be merged into 2.7 until it gives a tangible benefit to the 
maintenance branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

Well... ok. Although I already regard the patch as a strict bugfix (it fixes 
compilation of some C modules on MinGW), I'll go forward and create a patch for 
Python 3.2 which fixes compilation of all C modules on MinGW (all which are 
supposed to work on Win32 that is).

I assume once I've shown that the patch still mostly consists of some 
preprocessor fixes, it will have a fair chance of being applied in 2.7. If 
somebody knows that there is *no* chance, please speak *now* so I can just stop 
trying to make something that already works for me available to everybody.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Why exactly are you skeptical? Because it doesn't fix everything in
> one go? The other changes are also minimal (I'm not even sure if it
> requires more source changes, maybe I have just to get my #defines
> right). If you prefer to see a single patch which you can reproduce
> to fix MinGW compilation completely, I'm willing to do that.

Only bug fixes are acceptable for the 2.7 branch. If this *doesn't*
actually fix the bug (i.e. allows building Python with mingw), then
it's not a bug fix. Mere "improvements" are not acceptable for that
branch.

We have a long tradition of people proposing patches "we need this
and that code to support this and that platform". Then, right after
applying the patch, they come back with more patches, and after
that with more patches. I can accept this for the trunk if it doesn't
break anything, but not for a maintenance branch. The objective should
be to have the minimal necessary amount of changes that just address
the goal of the maintenance branch (i.e. fixes). Work in progress
doesn't belong here (some will argue that work in progress doesn't
even belong to the trunk, but should be carried out in a separate
branch).

> Given that 2.7 is supposed to be a long time support version, I
> really think people should have a chance to use MinGW. The patch is
> trivial, but figuring out everything from the compiler error messages
> can be brain bending.

If this bug (which, unfortunately, hasn't been identified clearly,
either) ever gets fixed, I'm open for backporting it (with the
release manager's approval - it could also be considered as a new
feature - port to mingw - in which case it also would be out of
scope).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Since the patch does not completely fix the mingw32 build, I suggest to apply 
it only on 3.2, and continue to work on mingw32 support there.

Only after we will be able to discuss whether all the changes can be backported 
to 2.7, provided that they fix the mingw32 build.

2.7 is in maintenance mode, and should not accept a change that only gives 
progress to a larger development process.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

Why exactly are you skeptical? Because it doesn't fix everything in one go? The 
other changes are also minimal (I'm not even sure if it requires more source 
changes, maybe I have just to get my #defines right). If you prefer to see a 
single patch which you can reproduce to fix MinGW compilation completely, I'm 
willing to do that.

Given that 2.7 is supposed to be a long time support version, I really think 
people should have a chance to use MinGW. The patch is trivial, but figuring 
out everything from the compiler error messages can be brain bending.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Please give me some starting point by applying these patches. I don't
> care if it's for 2.7.1 or 2.7.2. I'll try hard to get *everything*
> fixed, but we have to start somewhere.

I'm skeptical that we should do that with 2.7, then. So it would be
better to target 3.2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

I've revised the patch to use "defined(_MSC_VER) || defined(__MINGW32__)" as 
suggested.

And no, it does not solve all mingw compilition issues, but most of them. I've 
tried to only address the most obvious ones, which are *very* unlikely to break 
anything.

I have Python 2.7 completely compiling with MinGW (and even major parts of 
pywin32), but that requires some small changes to MinGW, too. I've also already 
started to submitting patches to the MinGW project.

Please give me some starting point by applying these patches. I don't care if 
it's for 2.7.1 or 2.7.2. I'll try hard to get *everything* fixed, but we have 
to start somewhere.

--
Added file: http://bugs.python.org/file19782/Python-2.7.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I doubt this fix will be enough to fix compilation with mingw32.

So somebody will have to verify independently. If it fails to fix
the bug completely, it's out of scope for 2.7 (it's out of scope for
2.7.1 IMO either way).

> With this patch, "#ifdef MS_WINDOWS" has the meaning of "linked with
> some version of MSVCRT". Do we agree on this, or is another symbol
> necessary?

MS_WINDOWS is defined as

MS_WINDOWS - Code specific to Windows, but all versions.

So it does *not* imply "MSVCRT". Introducing a new preprocessor symbol
is also out of scope for 2.7, so if we mean "MSC or mingw", we need
to spell that out (i.e. defined(_MSC_VER) || defined(__MINGW32__)).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I doubt this fix will be enough to fix compilation with mingw32.
But IMO it goes in the right direction.

With this patch, "#ifdef MS_WINDOWS" has the meaning of "linked with some 
version of MSVCRT".  Do we agree on this, or is another symbol necessary?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Roumen Petrov]

Changes by Roumen Petrov :


--
nosy: +rpetrov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

> What's the objective of this patch? I.e. what precisely is it supposed to 
> achieve?

So the answer is: It will fix compiling with gcc/MinGW by fixing the 3 issues 
described.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

Python 2.7 will currently not compile with MinGW for the outlined reasons.

* There are several "#if defined(_MSC_VER)" macros which surround Windows 
specific code/preprocessor fragments. But _MSC_VER is only defined with the 
Visual Studio compiler, not with gcc/MinGW. So the MS_WINDOWS define needs to 
be used for Windows specific code (and _MSC_VER only for compiler specific 
code).

* When cross-compiling on Unix with gcc/MinGW, the windows.h header is only 
found if it's written all lowercase due to Unix filesystems being 
case-sensitive.

* strcasecmp is a already defined by gcc/MinGW, so it must not be used for 
defining another function. The patch thus renames a function currently named 
strcasecmp to my_strcasecmp.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

What's the objective of this patch? I.e. what precisely is it supposed to 
achieve?

--
nosy: +loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

New submission from Johann Hanne :

There are a number of mingw compile issues which are easily fixed
* some "_MSC_VER" #if's should be "MS_WINDOWS" instead
* for cross-compiling, windows.h should be all-lowercase
* mingw has a strcasecmp, so private implementations must not use that name

--
components: Build
files: Python-2.7.diff
keywords: patch
messages: 122122
nosy: jonny
priority: normal
severity: normal
status: open
title: Trivial mingw compile fixes
versions: Python 2.7
Added file: http://bugs.python.org/file19770/Python-2.7.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com