Project

General

Profile

Bug #14422

Ruby configuration options should not be reused for gem builds

Added by vo.x (Vit Ondruch) 10 months ago. Updated 9 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
[ruby-core:85247]

Description

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?

Associated revisions

Revision bb3db69e
Added by nobu (Nobuyoshi Nakada) 9 months ago

configure.ac: library options to MAINLIBS

  • configure.ac (MAINLIBS): moved library options for main program and static libruby, and append MAINLIBS to LIBRUBYARG_STATIC, as these libraries are not needed for linking to shared libruby. [Bug #14422]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62627 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 62627
Added by nobu (Nobuyoshi Nakada) 9 months ago

configure.ac: library options to MAINLIBS

  • configure.ac (MAINLIBS): moved library options for main program and static libruby, and append MAINLIBS to LIBRUBYARG_STATIC, as these libraries are not needed for linking to shared libruby. [Bug #14422]

Revision 0f3452f4
Added by nobu (Nobuyoshi Nakada) 9 months ago

Makefile.sub: link user32.lib

  • win32/Makefile.sub: always link user32.lib which provides a lot of very common library functions. [Bug #14422]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62629 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 62629
Added by nobu (Nobuyoshi Nakada) 9 months ago

Makefile.sub: link user32.lib

  • win32/Makefile.sub: always link user32.lib which provides a lot of very common library functions. [Bug #14422]

Revision d1d2235e
Added by nobu (Nobuyoshi Nakada) 9 months ago

Makefile.sub: need suffix

  • win32/Makefile.sub: fix missing suffix of user32.lib. [Bug #14422]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62630 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 62630
Added by nobu (Nobuyoshi Nakada) 9 months ago

Makefile.sub: need suffix

  • win32/Makefile.sub: fix missing suffix of user32.lib. [Bug #14422]

History

#1 [ruby-core:85249] Updated by nobu (Nobuyoshi Nakada) 10 months ago

vo.x (Vit Ondruch) wrote:

Our build flags are fully ABI-compatible with each other, so mismatches will not cause any problems at the C/C++/ABI level.

Possibly it can be true on Fedora, but no one guarantees it on other platforms, and for different $(CC) especially, in general.

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?

#2 [ruby-core:85250] Updated by Hanmac (Hans Mackowiak) 10 months ago

i had some problem when building wxWidgets gem for ruby (and testing it on osx)

i needed to check that both wxWidgets, ruby and my gem where both build with the same compiler,
and in cases of wxWidgets and my gem with same compiler flags like -std

thats why i am unsure about removing configuration options

#3 [ruby-core:85252] Updated by shevegen (Robert A. Heiler) 10 months ago

This sounds very much like fedora-specific problems rather than
a problem caused by ruby, to be honest.

#4 [ruby-core:85325] Updated by vo.x (Vit Ondruch) 10 months ago

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).

#5 [ruby-core:85326] Updated by vo.x (Vit Ondruch) 10 months ago

shevegen (Robert A. Heiler) wrote:

This sounds very much like fedora-specific problems rather than
a problem caused by ruby, to be honest.

This issue might suffer any binary distribution sooner or later, be it Fedora, Debian or even Homebrew on Mac. The only case where it doesn't really matter is when you build everything from scratch on the target system, because there you have the whole toolchain and it is run only on that specific environment.

Actually it would have never be issue if the -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 option, which pulls in some configuration file, was not among the parameters.

#6 [ruby-core:85882] Updated by vo.x (Vit Ondruch) 9 months ago

So I have another issue with the configuration options. I tried to enable GMP support in Ruby on Fedora. Therefore, the Ruby build now requires "gmp-devel" and the configuration scripts configures the ruby to link against GMP. So far so good.

But later, when I want to build binary packages, they fails and this is the mkmf.log content:

"pkg-config --exists libffi"
| pkg-config --libs libffi
=> "-lffi \n"
"gcc -o conftest -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.    -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection conftest.c  -L. -L/usr/lib64 -L. -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic  -m64   -lruby  -lpthread -lgmp -ldl -lcrypt -lm   -lc"
/usr/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2: 
3: int main(int argc, char **argv)
4: {
5:   return 0;
6: }
/* end */

Apparently, the "-lgmp" is problematic, since I don't have gmp-devel installed in the buildroot for other packages. The link option should not be propagated for gems. They should pick their requirements by their configuration scripts.

#7 Updated by nobu (Nobuyoshi Nakada) 9 months ago

  • Status changed from Open to Closed

Applied in changeset trunk|r62627.


configure.ac: library options to MAINLIBS

  • configure.ac (MAINLIBS): moved library options for main program and static libruby, and append MAINLIBS to LIBRUBYARG_STATIC, as these libraries are not needed for linking to shared libruby. [Bug #14422]

#8 [ruby-core:85934] Updated by vo.x (Vit Ondruch) 9 months ago

  • Status changed from Closed to Open

Thx for fixing the latter.

Unfortunately, this does not address the original issue. So is there any hope this will be improved upstream? I would like to avoid some rbconfig.rb hacks to remove the configuration flags in question.

Also available in: Atom PDF