<feed xmlns='http://www.w3.org/2005/Atom'>
<title>ruby.git/tool/m4/ruby_append_option.m4, branch v3_4_9</title>
<subtitle>The Ruby Programming Language</subtitle>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/'/>
<entry>
<title>Extract hardening CFLAGS to a special $hardenflags variable</title>
<updated>2024-06-11T10:48:55+00:00</updated>
<author>
<name>KJ Tsanaktsidis</name>
<email>kj@kjtsanaktsidis.id.au</email>
</author>
<published>2024-06-09T11:15:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=0ccb80d6bf57cd6e79ad622c024d3d0940ec6f3b'/>
<id>0ccb80d6bf57cd6e79ad622c024d3d0940ec6f3b</id>
<content type='text'>
This changes the automatic detection of -fstack-protector,
-D_FORTIFY_SOURCE, and -mbranch-protection to write to $hardenflags
instead of $XCFLAGS. The definition of $cflags is changed to
"$hardenflags $orig_cflags $optflags $debugflags $warnflags" to match.

Furthermore, these flags are _prepended_ to $hardenflags, rather than
appended.

The implications of doing this are as follows:

* If a CRuby builder specifies cflags="-mbranch-protection=foobar" at
  the ./configure script, and the configure script detects that
  -mbranch-protection=pac-ret is accepted, then GCC will be invoked as
  "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar". Since
  the last flags take precedence, that means that user-supplied values
  of these flags in $cflags will take priority.
* Likewise, if a CRuby builder explicitly specifies
  "hardenflags=-mbranch-protection=foobar", because we _prepend_ to
  $hardenflags in our autoconf script, we will still invoke GCC as
  "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar".
* If a CRuby builder specifies CFLAGS="..." at the configure line,
  automatic detection of hardening flags is ignored as before.
* C extensions will _also_ be built with hardening flags now as well
  (this was not the case by default before because the detected flags
  went into $XCFLAGS).

Additionally, as part of this work, I changed how the detection of
PAC/BTI in Context.S works. Rather than appending the autodetected
option to ASFLAGS, we simply compile a set of test programs with the
actual CFLAGS in use to determine what PAC/BTI settings were actually
chosen by the builder. Context.S is made aware of these choices through
some custom macros.

The result of this work is that:

* Ruby will continue to choose some sensible defaults for hardening
  options for the C compiler
* Distributors are able to specify CFLAGS that are consistent with their
  distribution and override these defaults
* Context.S will react to whatever -mbranch-protection is actually in
  use, not what was autodetected
* Extensions get built with hardening flags too.

[Bug #20154]
[Bug #20520]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This changes the automatic detection of -fstack-protector,
-D_FORTIFY_SOURCE, and -mbranch-protection to write to $hardenflags
instead of $XCFLAGS. The definition of $cflags is changed to
"$hardenflags $orig_cflags $optflags $debugflags $warnflags" to match.

Furthermore, these flags are _prepended_ to $hardenflags, rather than
appended.

The implications of doing this are as follows:

* If a CRuby builder specifies cflags="-mbranch-protection=foobar" at
  the ./configure script, and the configure script detects that
  -mbranch-protection=pac-ret is accepted, then GCC will be invoked as
  "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar". Since
  the last flags take precedence, that means that user-supplied values
  of these flags in $cflags will take priority.
* Likewise, if a CRuby builder explicitly specifies
  "hardenflags=-mbranch-protection=foobar", because we _prepend_ to
  $hardenflags in our autoconf script, we will still invoke GCC as
  "gcc -mbranch-protection=pac-ret -mbranch-protection=foobar".
* If a CRuby builder specifies CFLAGS="..." at the configure line,
  automatic detection of hardening flags is ignored as before.
* C extensions will _also_ be built with hardening flags now as well
  (this was not the case by default before because the detected flags
  went into $XCFLAGS).

Additionally, as part of this work, I changed how the detection of
PAC/BTI in Context.S works. Rather than appending the autodetected
option to ASFLAGS, we simply compile a set of test programs with the
actual CFLAGS in use to determine what PAC/BTI settings were actually
chosen by the builder. Context.S is made aware of these choices through
some custom macros.

The result of this work is that:

* Ruby will continue to choose some sensible defaults for hardening
  options for the C compiler
* Distributors are able to specify CFLAGS that are consistent with their
  distribution and override these defaults
* Context.S will react to whatever -mbranch-protection is actually in
  use, not what was autodetected
* Extensions get built with hardening flags too.

[Bug #20154]
[Bug #20520]
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove comments in tool/m4 from the generated configure</title>
<updated>2021-04-17T10:14:21+00:00</updated>
<author>
<name>Nobuyoshi Nakada</name>
<email>nobu@ruby-lang.org</email>
</author>
<published>2021-04-17T10:14:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=1f56238032482ab55db2a7cbf5c156b5ccc17526'/>
<id>1f56238032482ab55db2a7cbf5c156b5ccc17526</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Emacs friendliness [ci skip]</title>
<updated>2018-01-20T07:14:59+00:00</updated>
<author>
<name>shyouhei</name>
<email>shyouhei@b2dd03c8-39d4-4d8f-98ff-823fe69b080e</email>
</author>
<published>2018-01-20T07:14:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=583939602838ad9d39e8485df4c8a8e5f236b608'/>
<id>583939602838ad9d39e8485df4c8a8e5f236b608</id>
<content type='text'>
Just add comment by:
sed -i $'1i\\\n# -*- Autoconf -*-' tool/m4/*.m4

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61983 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Just add comment by:
sed -i $'1i\\\n# -*- Autoconf -*-' tool/m4/*.m4

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61983 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
</pre>
</div>
</content>
</entry>
<entry>
<title>refactor split configure.ac into files</title>
<updated>2018-01-20T07:05:25+00:00</updated>
<author>
<name>shyouhei</name>
<email>shyouhei@b2dd03c8-39d4-4d8f-98ff-823fe69b080e</email>
</author>
<published>2018-01-20T07:05:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ruby-lang.org/ruby.git/commit/?id=0664a6377a7fc51e6d96d7b69361cc457e248b00'/>
<id>0664a6377a7fc51e6d96d7b69361cc457e248b00</id>
<content type='text'>
This does not (yet) change anything. The generated configure file
is the identical to previous one (except several empty lines added
and deleted).

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61981 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This does not (yet) change anything. The generated configure file
is the identical to previous one (except several empty lines added
and deleted).

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61981 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
</pre>
</div>
</content>
</entry>
</feed>
