Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Build error on gcc9 #1222

Closed
Teteros opened this issue Jun 19, 2019 · 12 comments
Closed

Build error on gcc9 #1222

Teteros opened this issue Jun 19, 2019 · 12 comments

Comments

@Teteros
Copy link
Contributor

Teteros commented Jun 19, 2019 •
edited

A lot of these spit out from the JUCE lib.
Errors such as:

g++ -mfpmath=sse -msse2 -Wall -Werror OpenGL/CheckOpenGL.cpp -c  `cat buildtype.opt` -Ibin/packages/gc-7.4.16/include -IQt/ -I/usr/include/python2.7 `cat flagopts.opt`  -Werror=array-bou
nds -msse2 -fomit-frame-pointer -DFOR_LINUX -DQT_X11EXTRAS_LIB -I/usr/include/qt/QtX11Extras -I/usr/include/qt -I/usr/include/qt/QtCore -DQT_GUI_LIB -I/usr/include/qt/QtGui -DQT_CORE_LIB
  -DWITH_FAUST_DEV -DWITH_PD  -I/home/tete/boost_1_70_0 -I/home/tete/boost_1_67_0 -I/home/tete/boost_1_63_0 -I /usr/include/vst36 -I ~/SDKs/VST_SDK/VST2_SDK/ -I ~/SDKs/VST3\ SDK -I ~/SDK
s/vstsdk2.4/ -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unknown-pragmas -fno-strict-aliasing -Wmissing-field-initializers -Wnull-dereference  -Wduplicated-cond -W
duplicated-branches -Wlogical-op -Wrestrict -DUSE_QT5 -Wmissing-declarations -DNDEBUG   -Wno-class-memaccess  -Wno-parentheses -std=gnu++11 `pkg-config --cflags Qt5Gui --cflags Qt5Networ
k --cflags Qt5OpenGL --cflags Qt5Widgets --cflags Qt5WebKitWidgets --cflags Qt5WebKit --cflags Qt5Concurrent` -Ibin/packages/qhttpserver-master/src -I/home/tete/code/aursrc/radium/src/ra
dium-5.9.67/bin/packages/QScintilla_gpl-2.10.8/Qt4Qt5 -DQHTTPSERVER_EXPORT  -fPIC -Wno-deprecated-copy -Werror=array-bounds -msse2 -fomit-frame-pointer -DFOR_LINUX -DQT_X11EXTRAS_LIB -I/
usr/include/qt/QtX11Extras -I/usr/include/qt -I/usr/include/qt/QtCore -DQT_GUI_LIB -I/usr/include/qt/QtGui -DQT_CORE_LIB  -DWITH_FAUST_DEV -DWITH_PD -std=gnu++11 -DCOMPILE_EXECUTABLE -o
radium_check_opengl.o
In file included from ../../JuceLibraryCode/modules/juce_graphics/juce_graphics.h:121,
                 from ../../JuceLibraryCode/modules/juce_gui_basics/juce_gui_basics.h:57,
                 from ../../../audio/../pluginhost/JuceLibraryCode/modules/juce_audio_utils/juce_audio_utils.h:56,
                 from ../../../audio/../pluginhost/JuceLibraryCode/JuceHeader.h:18,
                 from ../../../audio/Juce_plugin_scanner.cpp:11:
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getAlpha()’:
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h:116:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<u
nnamed union>::comps[3]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  116 |     forcedinline uint8& getAlpha() noexcept           { return comps [indexA]; }
      |                                                                ~~~~~~~~~~~~~^
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getRed()’:
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h:117:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<u
nnamed union>::comps[2]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  117 |     forcedinline uint8& getRed() noexcept             { return comps [indexR]; }
      |                                                                ~~~~~~~~~~~~~^
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getGreen()’:
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h:118:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<u
nnamed union>::comps[1]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  118 |     forcedinline uint8& getGreen() noexcept           { return comps [indexG]; }
      |                                                                ~~~~~~~~~~~~~^
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getBlue()’:
../../JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h:119:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<u
nnamed union>::comps[0]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  119 |     forcedinline uint8& getBlue() noexcept            { return comps [indexB]; }
      |                                                                ~~~~~~~~~~~~~^

gcc --version
gcc (GCC) 9.1.0

*Note that clang 8.0 and setting USE_CLANG=1 in build_linux_common.sh compiles succesfully
So this is a gcc issue.

Doesn't look like 5.9.65 builds either on this gcc.
EDIT: gcc8 works, so yes confirmed to be gcc9
@Teteros Teteros changed the title [5.9.67] Build error on gcc 9.1.0+ Build error on gcc9 Jun 19, 2019
@kmatheussen
Copy link
Owner

kmatheussen commented Jun 19, 2019 via email

@kmatheussen
Copy link
Owner

kmatheussen commented Jun 20, 2019 via email

@Teteros
Copy link
Contributor Author

Teteros commented Jun 20, 2019 •
edited

Thanks compile with gcc9 works with this patch
(although it was malformed in the email so did it manually):

diff -aur --no-dereference radium-5.9.67.pristine/pluginhost/JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h radium-5.9.67.new/pluginhost/JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h
--- radium-5.9.67.pristine/pluginhost/JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h	2019-06-19 13:56:47.000000000 +0100
+++ radium-5.9.67.new/pluginhost/JuceLibraryCode/modules/juce_graphics/colour/juce_PixelFormats.h	2019-06-20 16:52:16.099421784 +0100
@@ -113,10 +113,11 @@
 
    #if JUCE_GCC
     // NB these are here as a workaround because GCC refuses to bind to packed values.
-    forcedinline uint8& getAlpha() noexcept           { return comps [indexA]; }
-    forcedinline uint8& getRed() noexcept             { return comps [indexR]; }
-    forcedinline uint8& getGreen() noexcept           { return comps [indexG]; }
-    forcedinline uint8& getBlue() noexcept            { return comps [indexB]; }
+    // No longer needed on gcc9
+    // forcedinline uint8& getAlpha() noexcept           { return comps [indexA]; }
+    // forcedinline uint8& getRed() noexcept             { return comps [indexR]; }
+    // forcedinline uint8& getGreen() noexcept           { return comps [indexG]; }
+    // forcedinline uint8& getBlue() noexcept            { return comps [indexB]; }
    #else
     forcedinline uint8& getAlpha() noexcept           { return components.a; }
     forcedinline uint8& getRed() noexcept             { return components.r; }

Will this be merged or can't easily be set conditinally for gcc9+ only?

Also is gcc or clang recommended to build radium on linux with in general?
clang build seems faster so far.

It would be convenient if USE_CLANG=1 could be set on environment, much like BUILDTYPE or RADIUM_QT_VERSION is, so that editing makefile by hand is not necessary, but that's a different issue.

@kmatheussen
Copy link
Owner

kmatheussen commented Jun 20, 2019 via email

@kmatheussen
Copy link
Owner

kmatheussen commented Jun 20, 2019 via email

@Teteros
Copy link
Contributor Author

Teteros commented Jun 20, 2019

The comment is wrong though. It's not that it's no longer needed, but
it doesn't compile in gcc9.

"no longer needed" in the context of gcc9 being default in the distro.
The original code there is annotated by JUCE devs as workaround for gcc<9, and gcc9 seems to bind to packed values now (or the workaround is bad)

Radium uses gcc 8, so I rather not want to spend time on this issue.

It's fine, I think it's a good heads up when the target updates to gcc9 eventually. Currently the AUR package is using clang, I might switch that back with above patch next radium version.

backtrace in the crashreporter crashes with clang for me

Interesting, I've tested the crash on radium built with USE_CLANG=1 and send you a ticket through the UI, everything seems to work. Have you received it?

@kmatheussen
Copy link
Owner

kmatheussen commented Jun 21, 2019 via email

kmatheussen added a commit that referenced this issue Jun 22, 2019
@kmatheussen
Build: Compile with clang instead of gcc if environment variable RADI…
b449f09 
…UM_USE_CLANG is set to 1. #1222
@kmatheussen
Copy link
Owner

It would be convenient if USE_CLANG=1 could be set on environment

Done. Called it RADIUM_USE_CLANG

@kmatheussen
Copy link
Owner

It's fine, I think it's a good heads up when the target updates to gcc9 eventually. Currently the AUR package is using clang, I might switch that back with above patch next radium version.

Just to elaborate my answer. To lower the amount of work I rather want to upgrade all of JUCE, not just a patch of it. And I also rather not want to upgrade juce right now (if there is a already a release containing a fix for this, which I doubt) since I upgraded juce just a few months ago, and it's a little bit of work to upgrade juce. I'm not 100% sure commenting out those lines is okay either, so I don't want that quick-fix in the repository. I do use the workaround on my main development computer though, which has gcc9, and it seems to run fine.

@kmatheussen
Copy link
Owner

I've also added a test now during startup to check if backtrace crashes, just to be sure. I guess clang should be fine to use on linux. It's good that clang is used/tested on more than one platform.

@Teteros
Copy link
Contributor Author

Teteros commented Apr 22, 2020

For the record, JUCE was updated in 5adf690 which fixed this issue, so the GCC9 note in README file linking to this issue can be safely removed @kmatheussen

@kmatheussen
Copy link
Owner

Thanks, fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kmatheussen @Teteros