config.guess manufacturer string?

[Ralf Corsepius]

Panu Matilainen wrote:
> On Thu, 19 Feb 2009, Ralf Corsepius wrote:
> 
>> Panu Matilainen wrote:
>>> On Wed, 18 Feb 2009, Dan Nicholson wrote:
>>>
>>>> On Wed, Feb 18, 2009 at 9:13 AM, Stepan Kasal <skasal at redhat.com> 
>>>> wrote:
>>>>>
>>>>> Actually, if you care about the host triplet used for rpm builds,
>>>>> that's something where config.guess is not directly involved.
>>>>>
>>>>> Most spec files call %configure.  That macro calls configure with
>>>>> option --build.  With that option given, configure does not call
>>>>> config.guess.
>>
>>>> The advantage of setting --build correctly is that autoconf macros
>>>> will use test against the triplet will work as expected. For instance
>>>> AC_PROG_CC will search for gcc with the host triplet prefixed. Right
>>>> now, it searches for x86_64-unknown-linux-gnu-gcc. That's not how gcc
>>>> is installed on fedora (nor with the -gnu, but that's a separate
>>>> matter).
>>>
>>> Right, there's /usr/bin/x86_64-redhat-linux-gcc instead, and quite 
>>> obviously the build tools should be configured to match within the 
>>> distro.
>> Please elaborate.
>>
>> Unlike you're saying, it's actually not obvious.
>>
>> /usr/bin/x86_64-redhat-linux-gcc only exists as legacy being installed 
>> in parallel to /usr/bin/gcc for cases where people are violently 
>> passing --build/--host/--target (such as current rpm).
> 
> Legacy?
Though this is a bit oversimplified, yes, they basically are legacy, to 
cater those rare occasions, when people explicitly need to refer to 
them. For native package building/compilation, this almost never is the 
case (I am not aware of any such case).

> Okay, but due to the current messup with redhat/pc/unknown, not 
> even rpm causes that name to be searched for.
Right.

Cause: The toolchains' components have been configured using 
--target={i386|x86_86|..]-redhat-linux, while the magic inside of 
config.guess is detecting the OS it is running on as 
*-[pc|unknown]-linux-gnu

The config.guess magic is based on using nm (uname) => there is a 
mismatch between the toolchain's configuration and the origin of uname, 
i.e. whoever sets up uname's guts these days, likely the kernel or glibc 
  likely needs to be adjusted.

[IMHO, this mismatch is a long term historic wart RH-based distros 
inherited from RH's rpm's habit to copy config.guess and to override the 
defaults for $build/$host by passing --build/--host to %configure]

> Look, I'm asking here 
> because I don't know how this stuff is supposed to be set up, my "looks 
> obviously wrong" is just layman observation of a mismatch of "stuff".


> Hmm, so gcc gets the name for passing %{_target_platform} as --target to 
> configure. Which in turn is something else than %{_target}
Right. More precisely, many components of a GNU toolchain (esp. 
binutils, GCC, gdb) receive their target_prefix from the value being 
passed to their configure scripts through --target=TARGET


> (which is 
> something rpm uses this for it's internal purposes), which is still 
> different from %{_build}, nice little mess...
I know - You are scratching at the tip of the iceberg which breaks 
cross-building rpms (note: I am referring to building rpms for other 
platforms/OSes but Fedora/RH, e.g. building suse rpms on Fedora, 
rpmbuild --target=i586-suse-linux)


> [pmatilai at localhost ~]$ rpm --eval "%{_target}"
> x86_64-linux
> [pmatilai at localhost ~]$ rpm --eval "%{_build}"
> x86_64-unknown-linux-gnu
> [pmatilai at localhost ~]$ rpm --eval "%{_target_platform}"
> x86_64-redhat-linux-gnu
Another bug.

Their defaults all should be identical and match the value returned by 
config.guess.

> I'm getting somewhat mixed signals in this thread as to what %configure 
> should do. Is it
> a) set *none* of --build, --target and --host (how do you set up a
>    cross-build environment if that's the case?)

With modern autotools: configure --host=HOST


build ... the system the you are building on, defaults to the
    value returned by config.guess

host ... the system the binaries being generated for are supposed
    to run on. Causes configure scripts to use HOST-<tool> instead
    of <tool>

target ... Only useful when building cross tools. Not useful in
    in the overwhelming majority of cases.

> b) set only --build and add some conditional extra macros for passing in
>    cross-build options

In general, passing --build is almost never required, nor does it have 
any major impact, but to circumvent config.guess.


> c) something else, what exactly?

> And then related to above the manufacturer string, which is currently a 
> complete mixup between rpm's notion of "vendor" and config.guess notion 
> of "manufacturer", largely due to this:
> 
> %_target_platform       %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu}
> 
> [pmatilai at localhost ~]$ rpm --eval "%{_target_vendor}"
> unknown
> [pmatilai at localhost ~]$ rpm --eval "%{_vendor}"
> redhat
> 
> If the answer to the above %configure question is a), this doesn't make 
> much of a difference I guess, except perhaps to gcc which is passing 
> explicit --target %{_target_platform} (whether that can be dropped then 
> or not I dunno). In case it's b) this is much more visible: do we want 
> the "redhat" there or not?
Check what happens to %configure with rpmbuild --target=<...>
and you'll likely know the answer :(=)

I'd recommend you to experiment with the package enclosed below, passing 
different values to --build, --host, --target ... using the mingw32 
cross toolchain as example for a cross-toolchain

Try things such as:
configure
configure --host=i686-pc-mingw32
configure --build=x86_64-redhat-linux
configure --target=<whatever>
configure --build=i686-pc-mingw32

Ralf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crossex-20090219.tar.bz2
Type: application/x-bzip
Size: 65546 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090219/c16a80a0/attachment.bin>