Bug #18507: Incorrect target_os detection in configure script

• Status: Open
• Assignee: -
• Target version: -
• ruby -v: 3.1.0
• Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN

[rcl (Andrew Kosteltsev)]

configure.ac incorrectly detect target_os by target triplet such as arm-unknown-linux-gnueabihf. In case arm-unknown-linux-gnueabihf suffix we have incorrect ruby arch = 'arm-linux-eabihf' instead of 'arm-linux'.

configure.ac: 246:
target_os=echo $target_os | sed 's/linux-gnu$/linux/;s/linux-gnu/linux-/'

should be changed to:
target_os=echo $target_os | sed 's/linux-gnu[[^ ]]*$/linux/;s/linux-gnu/linux-/'

and correspondently configure: 7619:
target_os=echo $target_os | sed 's/linux-gnu$/linux/;s/linux-gnu/linux-/'

should be changed to:
target_os=echo $target_os | sed 's/linux-gnu[^ ]*$/linux/;s/linux-gnu/linux-/'

[nobu (Nobuyoshi Nakada)]

It seems like intentional, as there is the second substitution.
Is arm-linux-eabihf incorrect?

[rcl (Andrew Kosteltsev)]

In case 'arm-unknown-linux-gnueabihf' GNU Autotools recognizes target_os as 'linux-gnueabihf' (and 'linux-gnu' if 'arm-unknown-linux-gnu'). But ruby has own function for getting target_os during configuration process. I think there are no resons to set up ruby for both architectures (arm with soft fp engine and arm with hard fp) on one machine. If it is true then we can define target_os as 'linux' without any suffix.

If you want to set up ruby for several arch at the same time then you can stay with 'linux-eabihf'. However, this will create problems for distributors due to the disagreement in determining the target_os by GNU Autotools and determining the target_os by configure script from RUBY.

Any case the 'linux-eabihf' is not correct name for target_os.