930232 - Allow building with MinGW on Win32

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Tarnyko]

Attachment: pratom_h-mingw.patch

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 (Beta/Release)
Build ID: 20130215130331

Steps to reproduce:

Trying to compile NSPR on Win32 using MinGW,


Actual results:

build failed due to MSVC++-specific function mappings (_InterlockedIncrement() e.g.).


Expected results:

This patch adds a test for MinGW and maps the minimal needed functions.

Comment 1

[Wan-Teh Chang]

Jacek, could you explain how you made pratom.h work with MinGW in bug 594738?
Thanks.

Comment 2

[Tarnyko]

Attachment: pratom_h-mingw.patch

Attached a new and more complete patch ; the former one wasn't enough to allow some NSPR dependencies to build (NSS e.g.). Sorry for that.

Details :

- we now include <windows.h> here. If we don't do this, each file requiring PR_ATOM function will be required to include <windows.h> itself, which may not be portable/transparent for a developer.

- MinGW doesn't have the undescored version of functions, as can be seen in :
https://gitorious.org/mingw/mingw-w32api/source/240e5bbe9b18a18f3c975ba5ac923a4c537f3bb6:include/winbase.h

Comment 3

[Tarnyko]

Hello, any news on this ?
Thanks.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

jc, is that something you could review? thanks

Comment 5

[Jacek Caban]

It seems to me that including windows.h in this header is desired nor needed. Any recent mingw-w64 version supports intrin.h, so it should work just fine. I'd need to know what's the exact problem with it.

Also, mingw should also be fine with sync* variant of PR_ATOMIC* macro, so if Windows intrins are problematic for some reason, we could probably change the header to use that instead.

But, I don't know what's the problem. I didn't do standalone builds for a long time, but I'm pretty sure that mingw build as part of Gecko works.

Comment 6

[Tarnyko]

Whoa, it's moving ^^.

<windows.h> set apart, this change was probably valid 6 years ago.
Meanwhile, MinGW-64 took prio over MinGW32 and lots of things changed. I don't have the build environment anymore, so I couldn't confirm anyway.

You can close this (or I'll do if I can).