Closed Bug 930232 Opened 8 years ago Closed 2 years ago

Allow building with MinGW on Win32

Categories

(NSPR :: NSPR, defect)

4.9.5
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: tarnyko, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

Attached patch pratom_h-mingw.patch (obsolete) — Splinter Review
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.
OS: All → Windows XP
Hardware: All → x86
Attachment #821299 - Attachment is patch: true
Attachment #821299 - Attachment mime type: text/x-patch → text/plain
Jacek, could you explain how you made pratom.h work with MinGW in bug 594738?
Thanks.
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
Attachment #821299 - Attachment is obsolete: true
Hello, any news on this ?
Thanks.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

jc, is that something you could review? thanks

Assignee: wtc → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(jjones)
QA Contact: jjones

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.

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).

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Flags: needinfo?(jjones)
You need to log in before you can comment on or make changes to this bug.