Fix mingw gcc-6.2 ICE. #2473

awson · 2016-11-04T11:03:11Z

I can now build HEAD supercollider with stock MSYS2 64-bit gcc compiler/libraries (no manual tools/libraries installation).

Perhaps, this should be submitted to boost in the first place, though.

I've also guarded this with __MINGW32__ since I'm not sure if another platform's GCCs suffer from the problem.

bagong · 2016-11-04T11:09:47Z

Wow, your name should be awesome ;)

crucialfelix · 2016-11-04T17:43:21Z

Needs testing. This is for 3.9 ?

bagong · 2016-11-04T17:45:59Z

Yea, untested so far. Change is in boost, as awson mentioned himself, so it might even need discussion ;) It's not trivial to test, because it requires a fitting build environment.

bagong · 2016-11-08T21:58:35Z

@awson, I tried the build, and it breaks in hidapi for me:

https://gist.github.com/bagong/dd42da9bf990bc11e621eb0a2a53a9f4

Unfortunately I won't be around to follow up on this during the next 2 months and it is therefore possible that you don't get much feedback on this interesting pull request, I am sorry to say. I like msys2, and it provides an interesting alternative for qt, as the msys2 maintainers provide webkit in qt5.6 too - which is not the case in the official Qt distribution. Oth I must also say, that there is a strong trend to move towards Visual Studio among the persons working for the Windows version of SC. So while it would be very cool of course, if you were interested in maintaining a MinGW/msys build, atm it will likely not be an effort with much help by others.

awson · 2016-11-09T05:33:36Z

Yeah, a couple of small patches to hidapi (and supercollider proper) is required.
OK, if anybody is interested in stock MSys2 build, I'll put them into.

bagong · 2016-11-09T06:28:03Z

That would be great!

…rhaps breaks old headers build).

awson · 2016-11-09T10:46:43Z

Hidapi part.

bagong · 2017-01-30T13:30:30Z

Hi Awsome ( @awson )!

Sorry for taking so long to follow up on this, but I should be ready now if you are still available!

It's getting further and further. I get this error now:

[ 48%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/GC.cpp.obj
C:/Users/Rainer/Projects/sc/supercollider/lang/LangSource/GC.cpp: In member function 'bool PyrGC::BlackToWhiteCheck(PyrObject*)':
C:/Users/Rainer/Projects/sc/supercollider/lang/LangSource/GC.cpp:1036:31: error: cast from 'PyrObject*' to 'long unsigned int' loses precision [-fpermissive]
    if (objB && (unsigned long)objB < 100) {
                               ^~~~
make[2]: *** [lang/CMakeFiles/libsclang.dir/build.make:715: lang/CMakeFiles/libsclang.dir/LangSource/GC.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:2691: lang/CMakeFiles/libsclang.dir/all] Error 2
make: *** [Makefile:139: all] Error 2

mossheim · 2017-01-30T13:41:05Z

Oof. The "cast loses precision" complaint used to be a warning, not an error. We should really cleanup things like that. Is there a strictness command-line parameter you can invoke to get around that complaint for now?

bagong · 2017-01-30T14:07:32Z

@brianlheim : yes, -fpermissive allows the build to get past that point. I ran into a linker error with portaudio in sclang now. Probably that would go if we used the msys2 provided PA. I'll have a look. The msys2 build is interesting for various reasons: a) it's very easy for Linux users to get used to, b) it might allow to run post install tests without major adaptations, c) it provides binary Webkit with Qt 5.6 and d) it's a very active, well maintained project...

bagong · 2017-01-30T15:38:21Z

Works! ;)

bagong · 2017-01-30T16:36:49Z

SuperNova gets close, but not quite. It seemed to be happy with installing a special "workaround"-package for dynamic linking in a Windows environment (dlfcn), but then still complained with:

[ 76%] Linking CXX executable Release/supernova.exe
C:/msys/usr/lib/libdl.a(t-d000352.o):fake:(.text+0x2): undefined reference to `__imp_dlclose'
C:/msys/usr/lib/libdl.a(t-d000358.o):fake:(.text+0x2): undefined reference to `__imp_dlopen'
C:/msys/usr/lib/libdl.a(t-d000359.o):fake:(.text+0x2): undefined reference to `__imp_dlsym'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [server/supernova/CMakeFiles/supernova.dir/build.make:107: server/supernova/Release/supernova.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:3733: server/supernova/CMakeFiles/supernova.dir/all] Error 2
make: *** [Makefile:139: all] Error 2

All in all it nevertheless feels we're close to MinGW/MSYS 64-bit build. I'd rather get that going and switch to msys2 than perpetuate the 'Qt-release-policy-dependant' MinGW build we're using for the 32-bit version atm. I'll look next how 32-bit-sc and sc3-plugins behave.

bagong · 2017-01-30T17:26:23Z

sc32 and sc3-plugins 32 and 64bit build fine (supernova not tested).

Using msys2 has another advantage: we're currently using portaudio with a hacked build system because our MinGW build requires cmake. The combination mingw/cmake isn't supported by PA. Switching to MSYS2 would allow to use the MSYS2-provided package on the MinGW side and build vanilla PA with Visual Studio - as supported by the PA maintainers. That would simplify SC-Portaudio maintenance significantly.

Building SC with MSYS differs from a linux build only in that you need to specify "MSYS Makefiles" as generator for cmake. If you are used to arch linux, you already know the package manager (it's a pacman clone)...

But supernova needs a bit of work...

mossheim · 2017-01-30T17:53:58Z

This is great, thank you for this @bagong!

I did some googling ("msys libdl undefined reference __dl_open") and I think you have to add -ldl to your linker options. I'm totally debugging-at-a-distance here, though, so just a suggestion. :)

vivid-synth · 2017-01-30T20:24:02Z

@awson thanks for this! Can you also submit this patch to the boost repo (https://github.com/boostorg/thread/blob/develop/include/boost/thread/executors/basic_thread_pool.hpp ) so that we don't get further out of sync w Boost? Thanks!

awson · 2017-01-31T07:32:51Z

Well, I've revised my (already old) patches and found an old one missed related to if (objB && (unsigned long)objB < 100) line – we need to patch it to be if (objB && (uintptr_t)objB < 100) (-fpermissive isn't quite a correct solution since it affects things globally).

But I never ever had any problems with supernova – it was built without the hitch. Perhaps -ldl flag was picked by CMAKE automatically during a configuration phase?

bagong · 2017-01-31T09:48:46Z

Thanks @awson for for staying in the loop. I was not suggesting to introduce -fpermissive globally, I just used to see how far I would get with it. Could you add your patch to this pull request (and maybe others of similar nature ;) )?

I will look into the supernova problem, after all the main reason to keep up a MinGW build is supernova. Prior to the error-message I posted, I had another error claiming that dlfcn.h was missing. I worked around that by installing the package mingw-w64-i686-dlfcn, which in turn produced the error I reported. Should I uninstall the dlfcn package (which I think is controversial) again and go on from there (investigate -ldl) or is dlfcn required for the MSYS2 supernova build?

bagong · 2017-02-04T22:44:14Z

common/SC_Win32Utils.h

@@ -49,7 +49,6 @@
 #define basename win32_basename
 #define dirname win32_dirname
 #define pipe win32_pipe
-typedef int pid_t;


Removing this breaks the VS build.

bagong

While I am not in a position to comment on this, I have verified that this fixes a long standing bug in the MinGW compiler line that blocked MinGW builds above gcc 4.82 on Master. We need this, and we cannot wait for boost... (we should keep track of boost changes, though...). I will submit a PR soon, that integrates the MSYS2 option into the SC Windows build system. Thank you very much, Awson!
PS: The supernova errors disappeared, but I did have to install the dlfc package in MSYS2/MinGW...

This means we have a working 64-bit MinGW build now, and the Qt55-Webkit block is removed on the MinGW line. If readline7 were working this would be the first feature complete Windows build including supernova ;)

mossheim · 2017-02-07T17:54:06Z

I know I'm coming late to this, but I don't understand why the change had to be made in a Boost header; it's not apparent from the linked Gist. Is there a discussion somewhere else where this was diagnosed?

awson · 2017-02-07T18:48:02Z

Hmm, while the offending code is located further down the callstack than the code referred in the gist, the latter is a Boost header's code: C:/Users/Rainer/Projects/sc/supercollider/external_libraries/boost/boost/thread/detail/invoke.hpp:102:43: internal compiler error: in gimplify_expr, at gimplify.c:8343 return (*boost::forward<A0>(a0)).*f.

mossheim · 2017-02-07T19:48:02Z

But these warnings/errors are occurring within the context of translation unit PyrObject.cpp... In order to blame this on Boost someone would have to try compiling the Boost header in a less complex situation. This situation looks suspect (lines 43-54 of PyrObject.cpp):

#include <boost/range/irange.hpp> // first boost include

#define BOOST_THREAD_VERSION 4 // define boost marcos without explanation
#define BOOST_THREAD_PROVIDES_EXECUTORS

#include <boost/thread/future.hpp> /* compiler error happens here */
#include <boost/thread/executor.hpp>
#include <boost/thread/executors/basic_thread_pool.hpp>

#ifdef _MSC_VER
#include <future> // ifdef'd include, also for `future`
#endif

awson · 2017-02-07T20:20:07Z

Well, this is enough to make gcc ICEing:

#define BOOST_THREAD_VERSION 4
#include <boost/thread/executors/basic_thread_pool.hpp>

void ICE()
{
	boost::basic_thread_pool pool( 4 );
}

Nothing suspicious. Plain and simple gcc bug on purest Boost code.

mossheim · 2017-02-07T21:22:40Z

The versions of Boost headers/libraries in this repo span 1.0.45-1.0.61, and chrono, thread, and system are themselves from three close but different versions. So no, not exactly 'purest Boost code'...

Anyway, I'm OK with this change since it's been so thoroughly tested and only affects minGW.

bagong · 2017-02-07T21:39:14Z

Do we have an organized way of identifying boost patches in SC? I know of two for Windows (including this one). We could keep them somewhere for quick reference if ever a boost reform is done...
I only tested if the builds work, @brian, you know that. If you have a way to test for functionality, let me know. Otherwise I still think this brings us further than we were...

mossheim · 2017-02-07T21:41:42Z

I made a note of it in our projects here: https://github.com/supercollider/supercollider/projects/2#card-1643180

I would like somewhere a little more prominent... maybe we should just open an issue for updating the Boost libraries, and then we can collect this information there.

bagong · 2017-02-07T21:52:17Z

I added the other patch (#2457) I know of.

awson · 2017-02-07T21:55:44Z

I've just checked. ICE is here for the latest and greatest stock-single-version-consistent-homogeneous-blessed-don't_know_what_else MSYS2/mingw64 boost-1.63 + gcc-6.3.

bagong · 2017-02-07T21:59:04Z

It is at the super bowl too! :)
https://www.ice.gov/features/superbowl
And boost for kids has it too:
https://boostforkids.org/programs/internet-child-exploitation/

mossheim · 2017-02-07T22:17:11Z

I've just checked. ICE is here for the latest and greatest stock-single-version-consistent-homogeneous-blessed-don't_know_what_else MSYS2/mingw64 boost-1.63 + gcc-6.3.

I really appreciate you checking that, thank you.

Sounds like if we wait long enough, ICE might not be a problem at all:

http://www.telegraph.co.uk/news/2017/01/14/fast-arctic-ice-melting-meet-british-scientist-risked-polar/

mossheim · 2017-02-13T03:24:01Z

Merged after lots of testing documented in #2704.

Fix mingw gcc-6.2 ICE.

6654305

crucialfelix added this to the 3.9 milestone Nov 4, 2016

crucialfelix added comp: build CMake build system waiting for testing labels Nov 4, 2016

bagong added the changes-requested label Nov 8, 2016

Build supercollider against latest mingw-w64 headers (not guarded, pe…

e131cf7

…rhaps breaks old headers build).

awson mentioned this pull request Nov 9, 2016

Build hidapi against latest mingw-w64 headers supercollider/hidapi#5

Merged

vivid-synth added the os: Windows label Nov 18, 2016

bagong reviewed Feb 4, 2017

View reviewed changes

bagong added 2 commits February 6, 2017 16:22

Avoid breaking VS build.

c222ee8

Fix bad cast as suggested by awson. Thanks

c8365f9

bagong approved these changes Feb 6, 2017

View reviewed changes

bagong removed the changes-requested label Feb 6, 2017

bagong removed the waiting for testing label Feb 6, 2017

bagong mentioned this pull request Feb 7, 2017

Update Windows build system to support MSYS2 builds properly #2704

Merged

vivid-synth mentioned this pull request Feb 10, 2017

Use submodules for Boost #2301

Closed

mossheim merged commit 9207253 into supercollider:master Feb 13, 2017

mossheim mentioned this pull request Feb 13, 2017

Specify minimum build requirements for each platform, scsynth/supernova #2143

Closed

mossheim mentioned this pull request Mar 5, 2017

(bad) boost: import boost-1.63, update boost.sync #2772

Closed

3 tasks

dyfer mentioned this pull request Jan 22, 2023

basic_thread_pool.hpp and MinGW boostorg/thread#378

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix mingw gcc-6.2 ICE. #2473

Fix mingw gcc-6.2 ICE. #2473

awson commented Nov 4, 2016

bagong commented Nov 4, 2016

crucialfelix commented Nov 4, 2016

bagong commented Nov 4, 2016

bagong commented Nov 8, 2016

awson commented Nov 9, 2016

bagong commented Nov 9, 2016

awson commented Nov 9, 2016

bagong commented Jan 30, 2017

mossheim commented Jan 30, 2017

bagong commented Jan 30, 2017 •

edited

bagong commented Jan 30, 2017

bagong commented Jan 30, 2017 •

edited

bagong commented Jan 30, 2017 •

edited

mossheim commented Jan 30, 2017

vivid-synth commented Jan 30, 2017

awson commented Jan 31, 2017

bagong commented Jan 31, 2017 •

edited

bagong Feb 4, 2017

bagong left a comment •

edited

mossheim commented Feb 7, 2017

awson commented Feb 7, 2017

mossheim commented Feb 7, 2017

awson commented Feb 7, 2017

mossheim commented Feb 7, 2017 •

edited

bagong commented Feb 7, 2017 •

edited

mossheim commented Feb 7, 2017

bagong commented Feb 7, 2017

awson commented Feb 7, 2017

bagong commented Feb 7, 2017 •

edited

mossheim commented Feb 7, 2017

mossheim commented Feb 13, 2017

Fix mingw gcc-6.2 ICE. #2473

Fix mingw gcc-6.2 ICE. #2473

Conversation

awson commented Nov 4, 2016

bagong commented Nov 4, 2016

crucialfelix commented Nov 4, 2016

bagong commented Nov 4, 2016

bagong commented Nov 8, 2016

awson commented Nov 9, 2016

bagong commented Nov 9, 2016

awson commented Nov 9, 2016

bagong commented Jan 30, 2017

mossheim commented Jan 30, 2017

bagong commented Jan 30, 2017 • edited

bagong commented Jan 30, 2017

bagong commented Jan 30, 2017 • edited

bagong commented Jan 30, 2017 • edited

mossheim commented Jan 30, 2017

vivid-synth commented Jan 30, 2017

awson commented Jan 31, 2017

bagong commented Jan 31, 2017 • edited

bagong Feb 4, 2017

Choose a reason for hiding this comment

bagong left a comment • edited

Choose a reason for hiding this comment

mossheim commented Feb 7, 2017

awson commented Feb 7, 2017

mossheim commented Feb 7, 2017

awson commented Feb 7, 2017

mossheim commented Feb 7, 2017 • edited

bagong commented Feb 7, 2017 • edited

mossheim commented Feb 7, 2017

bagong commented Feb 7, 2017

awson commented Feb 7, 2017

bagong commented Feb 7, 2017 • edited

mossheim commented Feb 7, 2017

mossheim commented Feb 13, 2017

bagong commented Jan 30, 2017 •

edited

bagong commented Jan 30, 2017 •

edited

bagong commented Jan 30, 2017 •

edited

bagong commented Jan 31, 2017 •

edited

bagong left a comment •

edited

mossheim commented Feb 7, 2017 •

edited

bagong commented Feb 7, 2017 •

edited

bagong commented Feb 7, 2017 •

edited