Panu Matilainen wrote:
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).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@xxxxxxxxxx> 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?
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@localhost ~]$ rpm --eval "%{_target}"
x86_64-linux
[pmatilai@localhost ~]$ rpm --eval "%{_build}"
x86_64-unknown-linux-gnu
[pmatilai@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 ita) 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@localhost ~]$ rpm --eval "%{_target_vendor}"
unknown
[pmatilai@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
Attachment:
crossex-20090219.tar.bz2
Description: application/bzip
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
