Remove stack smashing protector for Clang compilers for ruby-builds #12

goldhoorn · 2015-03-23T11:43:33Z

No description provided.

marvin2k · 2015-03-24T14:40:29Z

modules/RockRuby.cmake

this option is only understood by gcc-4.9 and later -- I wonder how this crept into the build-environment?

On 24.03.2015 15:40, marvin2k wrote:

In modules/RockRuby.cmake
#12 (comment):

@@ -266,6 +266,11 @@ ELSEIF(NOT RUBY_EXTENSIONS_AVAILABLE)
OUTPUT_VARIABLE RUBY_CFLAGS)
STRING(REPLACE "\n" "" RUBY_CFLAGS ${RUBY_CFLAGS})

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")

#Clang can't handle this option (04.2014) remove this flag therefore

STRING(REPLACE "-fstack-protector-strong" "" RUBY_CFLAGS ${RUBY_CFLAGS})

this option is only understood by |gcc-4.9| and later -- I wonder how
this crept into the build-environment?

—
Reply to this email directly or view it on GitHub
https://github.com/rock-core/base-cmake/pull/12/files#r27033509.

I don't know who injects this. If i calling RBConfig it is present in
the cflags already..

Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengeschäftstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: [email protected]

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

sidenote: clang-3.4 chokes on the option, while clang-3.5 and later will eat it happily. Maybe your ruby (and RbConfig) used/saw a different compiler than you actually use?

I guess that he is on a system where ruby got compiled using gcc and he is using clang

On 24.03.2015 16:47, Sylvain Joyeux wrote:

In modules/RockRuby.cmake
#12 (comment):

@@ -266,6 +266,11 @@ ELSEIF(NOT RUBY_EXTENSIONS_AVAILABLE)
OUTPUT_VARIABLE RUBY_CFLAGS)
STRING(REPLACE "\n" "" RUBY_CFLAGS ${RUBY_CFLAGS})

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")

#Clang can't handle this option (04.2014) remove this flag therefore

STRING(REPLACE "-fstack-protector-strong" "" RUBY_CFLAGS ${RUBY_CFLAGS})

I guess that he is on a system where ruby got compiled using gcc and
he is using clang

—
Reply to this email directly or view it on GitHub
https://github.com/rock-core/base-cmake/pull/12/files#r27040782.

This is really possible ;).

Nevertheless how we handle this, in general the EABIs from clang and gcc
are compatible. So i see no reason why we should not workaround this here.

Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengeschäftstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: [email protected]

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

Nevertheless how we handle this, in general the EABIs from clang and gcc
are compatible. So i see no reason why we should not workaround this here.

Me neither

And just disabling the flag is kindof simple. Maybe testing for it is a better idea?

Maybe testing for it is a better idea?

👍

goldhoorn · 2015-03-25T08:04:58Z

updated

goldhoorn · 2015-03-25T09:28:25Z

updated and rebased

Tested on debian clang + gcc, assuming clang on macos will behave better now also

doudou · 2015-03-25T13:52:02Z

modules/RockRuby.cmake

There's IMO no need to keep the CLang test here. You check if the flag exists or not, that should be enough,

Disable smash-protection only if clang does NOT support it set noexecstack the correct way for clang

goldhoorn · 2015-03-25T13:56:33Z

There were only one cmake check left (you commented a outdated line)
I removed the last clang compiler check.

Regarding your last comment, i assume the gcc eats the -z and passes it automatically to the linker...

goldhoorn · 2015-04-01T10:37:52Z

pong?

doudou · 2015-04-01T12:48:14Z

There's still a question about

IF("${ARCH}" STREQUAL "")

protecting the noexecstack thing. Why not test it with a compiler check as well ?

goldhoorn · 2015-04-01T12:56:56Z

this wasn't intorduced by me, what should this block do?!

On 01.04.2015 14:48, Sylvain Joyeux wrote:

There's still a question about

|IF("${ARCH}" STREQUAL "")
|

protecting the noexecstack thing. Why not test it with a compiler
check as well ?

—
Reply to this email directly or view it on GitHub
#12 (comment).

--
Matthias Goldhoorn
Unterwasserrobotik

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: [email protected]

Weitere Informationen: http://www.dfki.de/robotik

Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

doudou · 2015-04-01T12:59:21Z

it was there before. I guess it checks whether noexecstack can be applied (somehow), hence my remark about changing it to the new scheme

goldhoorn · 2015-04-17T09:43:09Z

updated

Remove stack smashing protector for Clang compilers for ruby-builds

goldhoorn force-pushed the ruby-smash branch from 69126a6 to d62f1c3 Compare March 23, 2015 11:45

marvin2k reviewed Mar 24, 2015
View reviewed changes

goldhoorn force-pushed the ruby-smash branch from 793f179 to 082f03e Compare March 25, 2015 09:07

goldhoorn added 2 commits March 25, 2015 10:09

Remove stack smashing protector for Clang compilers for ruby-builds

83c4187

Remove -z noexecstack for on clang compilers

a039f77

goldhoorn force-pushed the ruby-smash branch from 082f03e to 3a5a407 Compare March 25, 2015 09:10

doudou reviewed Mar 25, 2015
View reviewed changes

Make compiler checks a bit less lazy

3225b2d

Disable smash-protection only if clang does NOT support it set noexecstack the correct way for clang

goldhoorn force-pushed the ruby-smash branch from 3a5a407 to 3225b2d Compare March 25, 2015 13:54

Check for noexexstack the right way instead diabling it hard on arm

6120dc7

doudou added a commit that referenced this pull request Apr 17, 2015

Merge pull request #12 from goldhoorn/ruby-smash

1b431e7

Remove stack smashing protector for Clang compilers for ruby-builds

doudou merged commit 1b431e7 into rock-core:master Apr 17, 2015

Remove stack smashing protector for Clang compilers for ruby-builds #12

Remove stack smashing protector for Clang compilers for ruby-builds #12

Uh oh!

Conversation

goldhoorn commented Mar 23, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goldhoorn commented Mar 25, 2015

Uh oh!

goldhoorn commented Mar 25, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goldhoorn commented Mar 25, 2015

Uh oh!

goldhoorn commented Apr 1, 2015

Uh oh!

doudou commented Apr 1, 2015

Uh oh!

goldhoorn commented Apr 1, 2015

Uh oh!

doudou commented Apr 1, 2015

Uh oh!

goldhoorn commented Apr 17, 2015

Uh oh!

Uh oh!