Bug 1265700 - rpm gets %{_host} incorrect on arm
rpm gets %{_host} incorrect on arm
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-23 09:49 EDT by Dennis Gilmore
Modified: 2016-02-03 05:13 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-03 05:13:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Gilmore 2015-09-23 09:49:43 EDT
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:
Comment 1 Florian Festi 2015-10-23 08:43:08 EDT
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.
Comment 2 Nicolas Chauvet (kwizart) 2015-10-29 10:44:54 EDT
@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...
Comment 3 Ľuboš Kardoš 2016-02-02 05:02:25 EST
> 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
Comment 4 Ľuboš Kardoš 2016-02-03 05:13:07 EST
> 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.

Note You need to log in before you can comment on or make changes to this bug.