Description of problem: [root@hathor ~]# uname -a Linux hathor.ausil.us 4.2.0-300.fc23.armv7hl+lpae #1 SMP Fri Sep 4 13:35:21 UTC 2015 armv7l armv7l armv7l GNU/Linux [root@hathor ~]# rpm -E %{_host} armv7hl-redhat-linux-gnueabi the triplet is supposed to be armv7hl-redhat-linux-gnu Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is set by the auto tools. macros.in reads %_host @host@ So what ever autoconf thinks is the right is put there. Please check your tool chain and reassign to autoconf/automake if necessary.
@Florian, I wonder if there isn't a circle dependency with the way the packages are built wrongly. Because usually %configure resolves the %{_host} macros that is coded to the following file in the rpm package. /var/lib/rpm/macros shows: %_host armv7hl-redhat-linux-gnueabi %_host_alias armv7hl-redhat-linux-gnueabi%{nil} So the previous macro is wrong in rpm, but to have it changed to something right, we need to pass it right in ./configure rpm spec file which is currently resolved as --build=armv7hl-redhat-linux-gnueabi --host=armv7hl-redhat-linux-gnueabi --with-vendor=redhat (again, which is wrong in resolving _target_platform): platform/armv7hl-linux/macros:%_target_platform %{_target_cpu}-%{_vendor}-%{_target_os} macros:%_target_os %{_host_os} macros:%_host_os linux So I don't know where is fetched the -gnueabi in target... I will have a look on gcc side and do some local tests to see if it's possible to bootstrap a local "fixed" rpm package...
> platform/armv7hl-linux/macros:%_target_platform > %{_target_cpu}-%{_vendor}-%{_target_os} > macros:%_target_os %{_host_os} > macros:%_host_os linux > > So I don't know where is fetched the -gnueabi in target... > It is fetched from /usr/lib/rpm/redhat/macros (redhat-rpm-config): %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu} > I will have a look on gcc side and do some local tests to see if it's > possible to bootstrap a local "fixed" rpm package... I created kind of that "fixed" rpm package by mistake and it caused some problems, see #1303265
> I wonder if there isn't a circle dependency with the way the packages are > built wrongly. Because usually %configure resolves the %{_host} macros that > is coded to the following file in the rpm package. Yes, now it is a circular dependency but the initial value for @host@ was got from the script config.guess in times when rpm.spec contained calling of configure script without parameter "--host %{_host}". The script config.guess is part of autotools so if this is a bug then it should be fixed in autotools at first. But I think this is intentional and when suffix is -gnu instead of -gnueabi on arm then problems arise (bug 1303265). I am closing this as not a bug.