343975 - Build system shouldn't use uname

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

In several places, the build system uses uname to determine os type, cpu, etc.

This disallows to build x86 binaries on amd64, or s390 on s390x.

While this can be fixed cleanly in nsprpub and the main configure script, which all use autotools, it would require some hacking for libnss...

Comment 1

[cls]

Can you be more specific?  Autoconf uses uname.  Building x86 binaries on 64bit machines is technically a cross-compile and we support that (for certain configurations).  NSS is a known problem child in this area but we have code in place to work around it (for certain configurations).

Comment 2

[Mike Hommey [:glandium]]

autoconf uses config.guess, which uses uname *and other logic* to decide what is going on. cross compiling is when the host system is different from the target system (--host and --target options ; host being autodetected with config.guess if not given).

Building x86 binaries on an amd64 host with the x86 toolchain is *not* cross compiling. Since you are using the x86 toolchain (and not an amd64 toolchain able to cross compile for x86, which is a different situation), host and target are identical.

In such a case, your uname detection will make the build use the amd64 assembly files, which will obviously fail, while the config.guess detection will make the build use the x86 assembly files.

I have a patch that we use on debian to build firefox and xulrunner, but it doesn't remove all the uname occurences, and may even break non GNU toolchain builds... (where uname and other logic is used to whatever it is used for in the configure.in)

Comment 3

[Mike Hommey [:glandium]]

Shouldn't the dependency be in the opposite direction ?

Comment 4

[cls]

This bug describes a general problem and the other bug provides a specific (partial) fix to the general problem.  Therefore, the general bug is dependent upon the specific bug. In essence, this is a meta bug since no one appears to be working on it and I would expect more dependencies to pop up over time.

Comment 5

[Bill Gianopoulos [:WG9s]]

(In reply to comment #4)
> This bug describes a general problem and the other bug provides a specific
> (partial) fix to the general problem.  Therefore, the general bug is dependent
> upon the specific bug. In essence, this is a meta bug since no one appears to
> be working on it and I would expect more dependencies to pop up over time.
> 

the fix in bug 372428 is sufficient to build x86 binaries on amd64.  I have no idea about s390 on s390x.

Comment 6

[Ramkumar R]

A workaround was suggested by syp_ on #[e-mail] using which I was able to build the x86 binaries on my amd64 machine: using setarch to force the arch detection to i686. The bug, however, is still valid because the root of the problem lies in config.guess which is guessing the architecture wrongly.

Comment 7

[Mike Hommey [:glandium]]

(In reply to comment #6)
> A workaround was suggested by syp_ on #[e-mail] using which I
> was able to build the x86 binaries on my amd64 machine: using setarch to force
> the arch detection to i686. The bug, however, is still valid because the root
> of the problem lies in config.guess which is guessing the architecture wrongly.

No, config.guess guesses the architecture right. But mozilla's configure doesn't use what config.guess returns everywhere, and relies on uname in some places where it really shouldn't.

Comment 8

[Ramkumar R]

(In reply to comment #7)
> No, config.guess guesses the architecture right. But mozilla's configure
> doesn't use what config.guess returns everywhere, and relies on uname in some
> places where it really shouldn't.

Ah, I see. Yes, my config.guess returns x86_64-unknown-linux-gnu while my uname returns 2.6.29-2-amd64. So somewhere, the value from uname is being used instead of the value from config.guess

Comment 9

[Chris Cooper [:coop] (he/him)]

Mass bug cleanup for Core:Build Config.

If you feel this bug has been closed in error, please re-open with new details.