[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
nobu@ruby-lang.org wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
matz@ruby-lang.org wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85325] [Ruby trunk Bug#14422] Ruby configuration options should not be reused for gem builds
From:
v.ondruch@...
Date:
2018-02-01 13:28:27 UTC
List:
ruby-core #85325
Issue #14422 has been updated by vo.x (Vit Ondruch). nobu (Nobuyoshi Nakada) wrote: > vo.x (Vit Ondruch) wrote: > > The question is why Ruby does this and how we can avoid this behavior. We could force installation of redhat-rpm-config package, providing the "/usr/lib/rpm/redhat/redhat-hardened-cc1", to every ruby user, but that does not seems right. There are also other similar issues discussing this situation [4], [5]. Any thoughts? > > Options given to configure as `XCFLAGS` and `XLDFLAGS` are used to build ruby itself, but not for extension libraries. > May this help you? Well, for configuration of every Fedora package, I should be using standard %configure macro, which by default defines CFLAGS and similar env variables. Of course I might opt to not use the %configure macro, but this means diverging from defaults and possibly causing different issues (e.g. the hardening options will be forgotten etc). ---------------------------------------- Bug #14422: Ruby configuration options should not be reused for gem builds https://bugs.ruby-lang.org/issues/14422#change-70111 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- When Fedora started to harden its packages, we quite often seen complains from our users about problems installing their gems, with errors such as [1]: ~~~ gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory ~~~ The issue as analyzed by Mamoru TASAKA is [2]: > Well, if I am not mistaken, the real problem here is that rpm's %optflags is always embedded into Fedora's ruby config file, that is > > /usr/lib64/ruby/rbconfig.rb:167: CONFIG["CXXFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic" > /usr/lib64/ruby/rbconfig.rb:171: CONFIG["CFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic -fPIC" > > on x86_64, for example. > > Although I am not sure this is already discussed somewhere or not, basically I think changing the default CFLAGS of "system" ruby like this way is undesirable and ? installed "rbconfig.rb" should have some "minimal" CFLAGS / CXXFLAGS. > ( for example, just like CONFIG["CFLAGS"] = "-fPIC" ) > > Only when we build Fedora gems or so (on koji), we should change CFLAGS / CXXFLAGS explicitly afterwards using %optflags. and Red Hat toolchain team responds [3]: > The current advice of the Red Hat toolchain team is to keep distribution build flags and toolchain default flags separate. This is why running “gcc” gives you the upstream defaults, and not the flags we use to compile Fedora packages. For consistency, Ruby (and other compilation support tools) follow this pattern: Use distribution flags when building for Fedora, but use upstream flags when the user compiles packages (i.e., what Ruby uses, probably something involving -O2). > > Our build flags are fully ABI-compatible with each other, so mismatches will not cause any problems at the C/C++/ABI level. The question is why Ruby does this and how we can avoid this behavior. We could force installation of redhat-rpm-config package, providing the "/usr/lib/rpm/redhat/redhat-hardened-cc1", to every ruby user, but that does not seems right. There are also other similar issues discussing this situation [4], [5]. Any thoughts? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c6 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c11 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1218294 [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1432191 -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>