[opensuse-factory] Why has -fstack-clash-protection been added to optflags?
Hi I've had build failures specifically on 42.3 packages that need gcc5 and up to build. The failures are due to -fstack-clash-protection, which only works with gcc7, having been added to %optflags. Strangely 42.2 builds with gcc5 don't have this flag. Is there any way to bypass this besides rewriting %optflags? Why is this flag in 42.3 builds but not 42.2? Why does this flag pass on gcc48? Thanks Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 23 Jan 2018, Dave Plater wrote:
Hi I've had build failures specifically on 42.3 packages that need gcc5 and up to build. The failures are due to -fstack-clash-protection, which only works with gcc7, having been added to %optflags. Strangely 42.2 builds with gcc5 don't have this flag. Is there any way to bypass this besides rewriting %optflags? Why is this flag in 42.3 builds but not 42.2? Why does this flag pass on gcc48?
gcc48 also supports this flag. I would suggest to change the packages requiring the non-system gcc5 to instead require gcc7. Richard.
Thanks Dave P
--
Richard Biener
On 23/01/2018 10:11, Richard Biener wrote:
gcc48 also supports this flag. I would suggest to change the packages requiring the non-system gcc5 to instead require gcc7.
I've done that with xine-lib and will do that with libmlt but audacity which has a gcc minimum of 4.9 has to build with the same version of gcc as wxWidgets-3_0-nostl which the 42.3 update package is built with gcc5. Packman doesn't seem to use the same optflags yet and I can disable and wipe binaries in multimedia:apps/audacity 42.3 but I suppose I'll have to rewrite optflags for 42.3 audacity. Roll on Leap:15. Why did this bite 42.3 and not 42.2? Thanks Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jan 23, 2018 at 10:57:24AM +0200, Dave Plater wrote:
On 23/01/2018 10:11, Richard Biener wrote:
gcc48 also supports this flag. I would suggest to change the packages requiring the non-system gcc5 to instead require gcc7.
I've done that with xine-lib and will do that with libmlt but audacity which has a gcc minimum of 4.9 has to build with the same version of gcc as wxWidgets-3_0-nostl which the 42.3 update package is built with gcc5. Packman doesn't seem to use the same optflags yet and I can disable and wipe binaries in multimedia:apps/audacity 42.3 but I suppose I'll have to rewrite optflags for 42.3 audacity. Roll on Leap:15. Why did this bite 42.3 and not 42.2?
I only enabled it on 42.3. Note that 42.2 goes EOL this week. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, This was me, I enabled it yesterday night again. Can you use "gcc7" or "gcc48" from 42.3:Update? Where is gcc5 coming from? I really would like to enable this security feature. Ciao, Marcus On Tue, Jan 23, 2018 at 10:01:12AM +0200, Dave Plater wrote:
Hi I've had build failures specifically on 42.3 packages that need gcc5 and up to build. The failures are due to -fstack-clash-protection, which only works with gcc7, having been added to %optflags. Strangely 42.2 builds with gcc5 don't have this flag. Is there any way to bypass this besides rewriting %optflags? Why is this flag in 42.3 builds but not 42.2? Why does this flag pass on gcc48? Thanks Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real
Hi,
This was me, I enabled it yesterday night again.
Can you use "gcc7" or "gcc48" from 42.3:Update? Any chance of a gcc5 update as well?
Where is gcc5 coming from? My home and multimedia:apps repos are fed from openSUSE:Leap:42.3:Update.
I really would like to enable this security feature.
Ciao, Marcus gcc7 is fine for all but audacity's 42.3 build. At the onset of 42.3 audacity had a minimum gcc requirement of 4.9 so I used gcc5 and found
On 23/01/2018 11:33, Marcus Meissner wrote: that wxWidgets-3_0-nostl also had to be built with gcc5, updates were made but this means that newer audacity's also have to build with gcc5 for 42.3. I'm assuming that -fstack-clash-protection must be a build option which wasn't used with gcc5 and gcc6. I'm going to wipe the multimedia:apps/audacity 42.3 binaries, it's still available in Packman for 42.3, their repos obviously don't link to 42.3 update, they should though. Thanks Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 23 Jan 2018, Dave Plater wrote:
On 23/01/2018 11:33, Marcus Meissner wrote:
Hi,
This was me, I enabled it yesterday night again.
Can you use "gcc7" or "gcc48" from 42.3:Update? Any chance of a gcc5 update as well?
Where is gcc5 coming from? My home and multimedia:apps repos are fed from openSUSE:Leap:42.3:Update.
I really would like to enable this security feature.
Ciao, Marcus gcc7 is fine for all but audacity's 42.3 build. At the onset of 42.3 audacity had a minimum gcc requirement of 4.9 so I used gcc5 and found that wxWidgets-3_0-nostl also had to be built with gcc5, updates were made but this means that newer audacity's also have to build with gcc5 for 42.3. I'm assuming that -fstack-clash-protection must be a build option which wasn't used with gcc5 and gcc6.
I can't see how anything sane would prevent using a newer compiler for any of the above packages. The compilers generate ABI compatible code after all, so unless audacity and friends do sth very stupid there shouldn't be an issue with building one of them with a newer compiler. Richard.
I'm going to wipe the multimedia:apps/audacity 42.3 binaries, it's still available in Packman for 42.3, their repos obviously don't link to 42.3 update, they should though. Thanks Dave P
--
Richard Biener
I can't see how anything sane would prevent using a newer compiler for any of the above packages. The compilers generate ABI compatible code after all, so unless audacity and friends do sth very stupid there shouldn't be an issue with building one of them with a newer compiler.
Richard. wxWidgets is very sensitive see: http://bugzilla.suse.com/show_bug.cgi?id=1074040 https://bugzilla.opensuse.org/show_bug.cgi?id=1051717 https://bugzilla.suse.com/show_bug.cgi?id=1030196 It's a pity I didn't choose gcc7 then but audacity appears to be very
On 24/01/2018 10:26, Richard Biener wrote: popular in our distribution. Another question, logic dictates that a package has to actually build with -fstack-clash-protection to benefit from it? Doesn't this mean that all 42.3 packages need to rebuild? BTW packman does connect to 42.3:Update, audacity fails to build there. Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 24 Jan 2018, Dave Plater wrote:
On 24/01/2018 10:26, Richard Biener wrote:
I can't see how anything sane would prevent using a newer compiler for any of the above packages. The compilers generate ABI compatible code after all, so unless audacity and friends do sth very stupid there shouldn't be an issue with building one of them with a newer compiler.
Richard. wxWidgets is very sensitive see: http://bugzilla.suse.com/show_bug.cgi?id=1074040 https://bugzilla.opensuse.org/show_bug.cgi?id=1051717 https://bugzilla.suse.com/show_bug.cgi?id=1030196 It's a pity I didn't choose gcc7 then but audacity appears to be very popular in our distribution.
Error message from console reads thus: audacity Fatal Error: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8). this seems to be a premature check done by wxWidgets / audacity? They appear to key on __GXX_ABI_VERSION but almost _nothing_ changes when this version changes. It's really only for corner cases like fixing mangling with vectors and attributes. For packages you could also simply downgrade the ABI version via -fabi-version=N (but then you'd have to have a way to communicate the ABI version chosen to compile wxWidgets to wxWidget users). There is also the corresponding -Wabi=N so you can instead do -Wabi=N (ABI version used to compile wxWidget). Can you somehow disable this checking for wxWidgets? It seems _really_ odd they invented this. Googling reveals the current upstream version has // GCC and Intel C++ share same C++ ABI (and possibly others in the future), // check if compiler versions are compatible: #if defined(__GXX_ABI_VERSION) // The changes between ABI versions 1002 through 1010 (documented at // https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html // under -fabi-version) don't affect wxWidgets, so we allow a library // and an application to differ within that range. #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1010)) #define wxGXX_EFFECTIVE_ABI_VERSION 1002 #else #define wxGXX_EFFECTIVE_ABI_VERSION __GXX_ABI_VERSION #endif so wouldn't have complained like in bnc#1074040. GCC 7 introduces version 11 which I bet also doesn't affect wxWidgets... quoting the docs: Version 11, which first appeared in G++ 7, corrects the mangling of sizeof... expressions and operator names. For multiple entities with the same name within a function, that are declared in different scopes, the mangling now changes starting with the twelfth occurrence. It also implies @option{-fnew-inheriting-ctors}. Just patch this insanity out ... Richard.
Another question, logic dictates that a package has to actually build with -fstack-clash-protection to benefit from it? Doesn't this mean that all 42.3 packages need to rebuild? BTW packman does connect to 42.3:Update, audacity fails to build there. Dave
--
Richard Biener
On 24/01/2018 12:02, Richard Biener wrote:
audacity Fatal Error: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8).
this seems to be a premature check done by wxWidgets / audacity? They appear to key on __GXX_ABI_VERSION but almost_nothing_ changes when this version changes. It's really only for corner cases like fixing mangling with vectors and attributes. For packages you could also simply downgrade the ABI version via -fabi-version=N (but then you'd have to have a way to communicate the ABI version chosen to compile wxWidgets to wxWidget users). There is also the corresponding -Wabi=N so you can instead do -Wabi=N (ABI version used to compile wxWidget).
Can you somehow disable this checking for wxWidgets? It seems_really_ odd they invented this.
Googling reveals the current upstream version has
// GCC and Intel C++ share same C++ ABI (and possibly others in the future), // check if compiler versions are compatible: #if defined(__GXX_ABI_VERSION) // The changes between ABI versions 1002 through 1010 (documented at //https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html // under -fabi-version) don't affect wxWidgets, so we allow a library // and an application to differ within that range. #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1010)) #define wxGXX_EFFECTIVE_ABI_VERSION 1002 #else #define wxGXX_EFFECTIVE_ABI_VERSION __GXX_ABI_VERSION #endif
so wouldn't have complained like in bnc#1074040. GCC 7 introduces version 11 which I bet also doesn't affect wxWidgets... quoting the docs:
Version 11, which first appeared in G++ 7, corrects the mangling of sizeof... expressions and operator names. For multiple entities with the same name within a function, that are declared in different scopes, the mangling now changes starting with the twelfth occurrence. It also implies @option{-fnew-inheriting-ctors}.
Just patch this insanity out ...
Richard.
Thanks Richard, you've given me some things to try out, maybe audacity built with gcc7 will work with wxWidgets built with gcc5. I've explored the abi check function in the past with intent to patch it out but had to use my time for other work. Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/01/2018 12:02, Richard Biener wrote:
Error message from console reads thus:
audacity Fatal Error: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8).
this seems to be a premature check done by wxWidgets / audacity? They appear to key on __GXX_ABI_VERSION but almost_nothing_ changes when this version changes. It's really only for corner cases like fixing mangling with vectors and attributes. For packages you could also simply downgrade the ABI version via -fabi-version=N (but then you'd have to have a way to communicate the ABI version chosen to compile wxWidgets to wxWidget users). There is also the corresponding -Wabi=N so you can instead do -Wabi=N (ABI version used to compile wxWidget).
Can you somehow disable this checking for wxWidgets? It seems_really_ odd they invented this.
Googling reveals the current upstream version has
// GCC and Intel C++ share same C++ ABI (and possibly others in the future), // check if compiler versions are compatible: #if defined(__GXX_ABI_VERSION) // The changes between ABI versions 1002 through 1010 (documented at //https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html // under -fabi-version) don't affect wxWidgets, so we allow a library // and an application to differ within that range. #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1010)) #define wxGXX_EFFECTIVE_ABI_VERSION 1002 #else #define wxGXX_EFFECTIVE_ABI_VERSION __GXX_ABI_VERSION #endif
so wouldn't have complained like in bnc#1074040. GCC 7 introduces version 11 which I bet also doesn't affect wxWidgets... quoting the docs:
Version 11, which first appeared in G++ 7, corrects the mangling of sizeof... expressions and operator names. For multiple entities with the same name within a function, that are declared in different scopes, the mangling now changes starting with the twelfth occurrence. It also implies @option{-fnew-inheriting-ctors}.
Just patch this insanity out ...
Richard. Seems I was panicking for no reason, audacity built with gcc7 in Leap:42.3 works fine with gcc5 built wxWidgets-3_0-nostl. Thanks all Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jan 24, 2018 at 11:13:35AM +0200, Dave Plater wrote:
I can't see how anything sane would prevent using a newer compiler for any of the above packages. The compilers generate ABI compatible code after all, so unless audacity and friends do sth very stupid there shouldn't be an issue with building one of them with a newer compiler.
Richard. wxWidgets is very sensitive see: http://bugzilla.suse.com/show_bug.cgi?id=1074040 https://bugzilla.opensuse.org/show_bug.cgi?id=1051717 https://bugzilla.suse.com/show_bug.cgi?id=1030196 It's a pity I didn't choose gcc7 then but audacity appears to be very
On 24/01/2018 10:26, Richard Biener wrote: popular in our distribution.
Another question, logic dictates that a package has to actually build with -fstack-clash-protection to benefit from it? Doesn't this mean that all 42.3 packages need to rebuild?
The idea is to slowly get packages rebuilt with this option just by releasing regular updates with other fixes. We can selectively update for instance setuid root applications just for this, but I have so far not specifically planned for that. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jan 24, 2018 at 6:13 AM, Dave Plater
wxWidgets is very sensitive see:
It is not sensitive.. it is just has some ill advised checks in place..just patch them away, pick the default compiler and it should be fine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Cristian Rodríguez -
Dave Plater -
Marcus Meissner -
Richard Biener