Topic: Error compiling with mingw

[Milko]

Hello James

I'm trying to compile last devel-new using mingw.

I obtain a strange error. Do you know how to solve?

Giuseppe

[jamespetts]

Hmm, that's odd. I don't normally compile with MinGW. These errors appear in files not altered by Experimental, so I do not really understand why you are getting errors in them.

[TurfIt]

Experimental appears to be missing several commits by tron in/around  May 2014 cleaning up things up. The specific problem in this file is missing includes... stdlib, basetyps...

[jamespetts]

Thank you for that. I think that I have fixed the compile issue now, although I cannot test this as I do not use MinGW. Giuseppe - can you re-test?

[Milko]

Hello James

First problem is now ok, but I now I have another error in win32_sound.cc

Giuseppe

[jamespetts]

I have made a possible fix - can you try it again now? Thank you for the reports.

[Milko]

Hello James

Now compile is ok. I have problem building the file.

Giuseppe

[jamespetts]

That is a very odd error, and a difficult one on which for me to advise, not knowing anything about that code and there not being any problems with MSVC or (apparently) with GCC on Linux. Can I ask you to test first of all cleaning the build ("make clean") and trying again, just in case there is some clash of old half-compiled files and the newer stuff?

[Milko]

Hello James

Test done, but build is KO again. May be someone know the libraries and know the source of the problem.

Giuseppe

[jamespetts]

This is very odd. Is it the same error again? I don't use MinGW, so it's hard for me to track this down. Can you try using MSVC, which is known to be working. Sorry that you're having trouble.

[Milko]

Hello James

Yes, error is the same.

It seems an error due to a double definition, I would not know how to track down the two different definitions.

Giuseppe

[TurfIt]

Experimental's makefile is FUBAR'd...
The specific problem here is including the same source file twice. Looks like bad merging of changes from Standard, so likely more issues. In general I gave up on Experimental due to the 'sabotages' embedded throughout to non-MSVC compilers - especially on Windows...

[jamespetts]

Ahh, that would explain why I could not find the thing being defined more than once. I am now staying with my parents for Christmas and cannot really fix this until I get back home in January.

TurfIt - what file was included twice? This is not really a "sabotage" to other compilers from Microsoft - it is just that MSVC does not use makefiles. There have been people building this on Linux with GCC, which I do for my server (although I have not built the latest development branch on my server), so there is not a general problem with Experimental and compilers other than MSVC; however, it is very rare for people to want to use MinGW (people usually use MSVC on Windows or GCC on Linux), so any problems specific to MinGW are hard to track down.

If you let me know the erroneous file, I can give Giuseppe instructions to fix it on his own copy pending me being able to fix it properly when I get back home next month.

Edit: I have just tried compiling with GCC (32-bit) on a very old and slow Linux computer at my parents' house, and it seems to work fine. It is very odd that the problem should be specific to MinGW.

[TurfIt]

The makefile has:

Code: [Select]

SOURCES += simsys_w32_png.cc twice for both cygwin and mingw. As previously stated, it appears as though the refactoring of the Standard makefile wasn't merged to Experimental correctly. I would suggest there's no need for any difference in the platform specific sections of the makefile between Standard and Experimental; Only differences in the files (SOURCES+=  section).

By sabotage I meant stuff like the first line of simsys_w32_png.cc:

Code: [Select]

#ifndef SDLresulting in the compiler skipping the entire file if trying to build the SDL version. I'd previously (4-5 years ago?)  even provided you a patch to remove all these strange contraptions allowing gcc to compile properly, but it was never fixed. Such inappropriate #ifs are in several other files too... Best guess is someone is trying to use these to control building of different targets rather than properly configuring their build system if not using the makefile which is already setup to handle that.

[jamespetts]

Thank you for that: that is most helpful. I have managed to set up Git on this old machine at my parents' house, merged the changes in the platform specific things in the Makefile from Standard, and pushed them back to the repository. Giuseppe, can you test whether this is working now?

As for the #ifndef SDL, etc., I added those a long time ago to allow for optional compilation of SDL and GDI using MSVC, which does not use the makefile. That was long before I learnt how to disable individual files from compiling in certain build settings in MSVC. I have not produced SDL builds for Windows for a very long time, so had never got around to doing anything about these.

[Milko]

WOW James, now it's OK!!!!!!

Thank's to all for supporting me :-)

Giuseppe

[jamespetts]

Excellent! Thanks especially to TurfIt for spotting the problem.