Fix building Premake using mingw #1111

tdesveauxPKFX · 2018-06-02T23:51:41Z

Only works with MinGW64 due to an error in luasocket.

I'd appreciate if someone that have used MinGW before could take a look.

samsinsane

LGTM, if nobody speaks up in by the end of the week, we should just merge it.

starkos

This seems reasonable to me…I don't have MinGW installed here to test.

tdesveauxPKFX · 2018-06-03T14:06:46Z

Well, I installed both MinGW32 and 64 and it works with MinGW64.

MinGW32 has an error related to curl if I remember correctly.

I expected a review on this part:

filter { "system:windows", "action:gmake*" }

I think it is pretty safe to assume that Makefiles on Windows are used with MinGW but just wanted to confirm it.

starkos · 2018-06-03T14:11:07Z

think it is pretty safe to assume that Makefiles on Windows are used with MinGW but just wanted to confirm it.

Could be Cygwin too, but I would still expect those libraries to be present. I think this should be okay.

tdesveauxPKFX · 2018-06-03T14:27:38Z

I though Cygwin used MinGW, I'm really confused about all these things. Let me test Cygwin to be sure;

If everything works fine, I will merge this myself if that's ok with you.

tdesveauxPKFX · 2018-06-03T15:24:21Z

Well, I can't build curl with the cygwin gcc but I think it is another issue than what this PR does.
The issue is ../../contrib/curl/lib/curl_setup_once.h:110:8: error: redefinition of ‘struct timeval’
which can be fixed with a define HAVE_STRUCT_TIMEVAL.

I think this is something for curl to fix and not us.
Anyway, Bootstrap would need a cygwin rule for this.

I also have an issue with mingw64 gcc in cygwin. Here is the log:

/usr/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/bin/ld: skipping incompatible /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libmingw32.a when searching for -lmingw32
/usr/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/bin/ld: skipping incompatible /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libmingw32.a when searching for -lmingw32
/usr/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/bin/ld: skipping incompatible /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libmingw32.a when searching for -lmingw32
/usr/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmingw32

Not sure what cause this, I will look into it some more.

tdesveauxPKFX · 2018-06-03T15:35:08Z

Well, it seems to be an issue on cygwin side. If someone want to build with MinGW, they should get MinGW not from cygwin.

If someone want to look into cygwin, I had to add change

premake-core/src/host/premake.h

Line 20 in d6dfaa3

#if defined(__linux__)

to

#if defined(__linux__) || defined(__CYGWIN__)

Anyway, that still fix an issue so I'm inclined to merge as is. I will merge this tomorrow to let the opportunity for people to disagree.

tdesveauxPKFX · 2018-06-03T19:05:17Z

I also have an issue with mingw64 gcc in cygwin. Here is the log:

Disregard this... I just forgot to add PLATFORM=x64 so it was building and looking for 32bit libraries.

I just added a fix in os_stat for MinGW32 if the curl problem is ever fixed and the Cygwin identification.

I tried to build with Cygwin for a correctly (with the PLATFORM=x64) and I currently have a seg fault on linking. Otherwise everything build.

TurkeyMan · 2018-06-05T00:45:14Z

I think it is pretty safe to assume that Makefiles on Windows are used with MinGW but just wanted to confirm it.

I'd like to think that's not a reasonable assumption; msc should work with makefiles too, but it's definitely not used often.

TurkeyMan · 2018-06-05T00:48:26Z

contrib/libzip/premake5.lua

@@ -16,6 +16,8 @@ project "zip-lib"

 	filter "system:windows"
 		defines { "_WINDOWS" }
+	filter { "system:windows", "action:gmake**" }


Yeah, I don't like this strategy... I feel like mingw/cygwin might be systems, but I'm not entirely sure :/

I feel like mingw/cygwin might be systems

I disagree, is there anything stopping you from using either of these to target Android or Linux? I'd be more inclined to say that these should fall under toolset, or a subtype of toolset/action.

Maybe... the distinction between mingw/cygwin and 'windows' is that they have a different runtime, different ABI, different libs. They are definitely a different platform than 'windows' (assuming an MSVC windows world).

I have often wanted to generate a makefile that uses MSVC because I want to share the same build system across platforms. I don't usually do it, but I feel like it should be possible to produce a makefile that supports the normal 'windows' ecosystem, in addition to mingw/cygwin.

Yeah nar. It's definitely not a toolset thinking on it. Mingw/cygwin are undeniably different platforms... or 'systems'?
Building mingw from windows is no different than building android from windows. The entire pipeline is incompatible with 'windows' by premakes conventional assumptions.

I really don't know enough about either of them to push for anything in particular, they just don't seem like systems to me.

TurkeyMan · 2018-06-05T00:49:00Z

src/host/premake.h

@@ -17,7 +17,7 @@

 /* Identify the current platform I'm not sure how to reliably detect
 * Windows but since it is the most common I use it as the default */
-#if defined(__linux__)
+#if defined(__linux__) || defined(__CYGWIN__)


Why do you want PLATFORM_STRING to be "linux" under cygwin?

cygwin == linux is kinda like saying bsd == linux no?

we don't... but the problem for example is that curl uses autoconf to generate most of it config header files. Since premake does not have such a facility, we pre-generated these header files. and checked them in.. and well, obviously they are wrong for some platforms. That's why for example mingw32 doesn't seem to work, because most of those header files have been generated on 64-bit linux variants....

it's a common recurring issue with 3rd party libraries that do this kind of thing, and we basically have to hand craft a header file that satisfies all platforms. It's why I created an autoconf module to try and somewhat remedy this. It was mostly a prototype proof of concept, and it's certainly not impossible to add such facilities to premake. I just don't like it. I feel like if you have to resort to autoconf tools, your doing something wrong.

That's why for example mingw32 doesn't seem to work

Not sure this is the cause but I should check it out. I think I saw a GitHub issue somewhere where someone had the same issue and the cause was MinGW32.

Why do you want PLATFORM_STRING to be "linux" under cygwin?

Building with Cygwin uses posix libraries. But this is an awful solution and should absolutely not be merged into master.
I had second though about this PR yesterday and definitely want to take another look at it now.

tdesveauxPKFX · 2018-06-05T08:14:27Z

I'd like to think that's not a reasonable assumption; msc should work with makefiles too, but it's definitely not used often.

One thing to consider is that Premake generated Makefiles cannot be used with NMake. So we would be talking about using a MinGW/Cygwin makefile binary to run a msc Makefile.

However, I agree that it's a somewhat bold assumption but I didn't see an alternative.
I never used MinGW nor Cygwin so this is a result of some hacking around on my part.
If someone want to take this on, I'd be grateful. Otherwise, I think I need to take another look at this.

TurkeyMan · 2018-06-09T00:35:20Z

So we would be talking about using a MinGW/Cygwin makefile binary to run a msc Makefile.

That's entirely feasible. Although supporting nmake is something I'd like to clean up too one day!

Yeah, I'm not happy with the assumption. It's rarely used, so I have no doubt that when it's committed, it'll 'stick', and it'll be that way forever :P

tdesveauxPKFX · 2018-07-19T18:12:20Z

Finally some time to look into this.

After some thoughts, I'd say that MinGW should be handled as a toolset.

In the same way you can build either with gcc or clang on Linux, you should be able to build with cl or MinGW on Windows with a Makefile. Well not really in the same way as MinGW and cl can't use the same options like gcc and clang does.

This way, the bootstrap can just use --cc=mingw.

…lding with mingw32

tdesveauxPKFX · 2018-07-19T22:28:19Z

So, the issue with MinGW32 come from luasocket.

wsocket.c
In file included from ../../binmodules/luasocket/src/wsocket.h:11:0,
from ../../binmodules/luasocket/src/socket.h:18,
from ../../binmodules/luasocket/src/wsocket.c:10:
../../binmodules/luasocket/src/wsocket.c: In function 'socket_gaistrerror':
../../binmodules/luasocket/src/wsocket.c:417:14: error: 'ERROR_NOT_ENOUGH_MEMORY' undeclared (first use in this function)
case EAI_MEMORY: return PIE_MEMORY;
^
../../binmodules/luasocket/src/wsocket.c:417:14: note: each undeclared identifier is reported only once for each function it appears in
luasocket.make:210: recipe for target 'obj/x86/Release/luasocket/wsocket.o' failed

The related github issue I was talking about last time: curl/curl#2361.

I'm giving up on MinGW32, so I think this PR is complete as is, just waiting on an approval (especially from @TurkeyMan).

If someone ever take up to make MinGW32 work, there is an issue with how the __declspec(dllexport) is declared. It is declared in the makefile and Premake escape the parenthesis which cause the build to fail.

I also removed the Cygwin change as it was bothering me and I feel (if someone ever want to make Cygwin work) that it should be a system so should be on a separate PR.

samsinsane · 2018-08-10T05:44:41Z

@tdesveauxPKFX @TurkeyMan are we good to merge this?

starkos · 2020-03-30T22:02:23Z

I rebased this to master, made some additional fixes, and created PR #1420. It isn't perfect, but it does provide a build path for MinGW users. Thanks to @tdesveaux for doing the hard parts.

samsinsane approved these changes Jun 3, 2018

View reviewed changes

starkos approved these changes Jun 3, 2018

View reviewed changes

tdesveauxPKFX force-pushed the fix-mingw branch from 8e26243 to 5ab5782 Compare June 3, 2018 14:48

tdesveauxPKFX force-pushed the fix-mingw branch from 5ab5782 to 4203ed3 Compare June 3, 2018 15:39

starkos approved these changes Jun 4, 2018

View reviewed changes

TurkeyMan reviewed Jun 5, 2018

View reviewed changes

tdesveaux added 2 commits July 19, 2018 22:53

os_stat: Use _stat instead of _stat64i32. Later is undefined when bui…

3b491c8

…lding with mingw32

Fix MinGW64 build

844b627

tdesveauxPKFX force-pushed the fix-mingw branch from 4829135 to 844b627 Compare July 19, 2018 20:56

samsinsane mentioned this pull request Sep 6, 2018

Generated make files are not compilable by MinGW #1156

Closed

starkos mentioned this pull request Mar 30, 2020

Fix MinGW builds of Premake #1420

Merged

5 tasks

starkos closed this Mar 30, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix building Premake using mingw #1111

Fix building Premake using mingw #1111

tdesveauxPKFX commented Jun 2, 2018

samsinsane left a comment

starkos left a comment

tdesveauxPKFX commented Jun 3, 2018

starkos commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

TurkeyMan commented Jun 5, 2018

TurkeyMan Jun 5, 2018

samsinsane Jun 5, 2018

TurkeyMan Jun 9, 2018

TurkeyMan Jun 9, 2018

samsinsane Jun 10, 2018

TurkeyMan Jun 5, 2018

TurkeyMan Jun 5, 2018

tvandijck Jun 5, 2018

tdesveauxPKFX Jun 5, 2018

tdesveauxPKFX commented Jun 5, 2018

TurkeyMan commented Jun 9, 2018

tdesveauxPKFX commented Jul 19, 2018

tdesveauxPKFX commented Jul 19, 2018

samsinsane commented Aug 10, 2018

starkos commented Mar 30, 2020

Fix building Premake using mingw #1111

Fix building Premake using mingw #1111

Conversation

tdesveauxPKFX commented Jun 2, 2018

samsinsane left a comment

Choose a reason for hiding this comment

starkos left a comment

Choose a reason for hiding this comment

tdesveauxPKFX commented Jun 3, 2018

starkos commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

tdesveauxPKFX commented Jun 3, 2018

TurkeyMan commented Jun 5, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tdesveauxPKFX commented Jun 5, 2018

TurkeyMan commented Jun 9, 2018

tdesveauxPKFX commented Jul 19, 2018

tdesveauxPKFX commented Jul 19, 2018

samsinsane commented Aug 10, 2018

starkos commented Mar 30, 2020