ghc-6.8 configure does not recognise 32bit userland on ppc64

[kahl@…]

Building 6.8 (2007.09.12 through 2007.09.17) out of the box with

./configure

make all

fails after half an hour with assembler errors indicating that it tries to compile 64bit code on a 32bit userland (on ppc64 gentoo, on the system running the buildbot). The build goes through with

    GhcUnregisterised=YES

    SplitObjs=NO

in mk/build.mk, but I think that the release should work without users editing mk/build.mk.

Wolfram

../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -optc-w -H16m -O -optc-O2 -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint     -c StgCRun.c -o StgCRun.o

/tmp/ghc16536_0/ghc16536_0.s: Assembler messages:

/tmp/ghc16536_0/ghc16536_0.s:11:0:
     Error: junk at end of line, first unrecognized character is `@'

/tmp/ghc16536_0/ghc16536_0.s:15:0:
     Error: junk at end of line, first unrecognized character is `@'

make[1]: *** [StgCRun.o] Error 1

make: *** [stage1] Error 1

[guest]

While the GHC build system identifies this machine (running 32bit userland on ppc64 64-bit kernel) as powerpc64-unknown-linux-gnu,

(in config.status:

s,@build@,|#_!!_#|powerpc64-unknown-linux-gnu,g

in config.log:

configure:1856: checking for GHC version date configure:1874: result: given 6.8.20070912 configure:2007: checking build system type configure:2025: result: powerpc64-unknown-linux-gnu configure:2047: checking host system type configure:2062: result: powerpc64-unknown-linux-gnu configure:2084: checking target system type configure:2099: result: powerpc64-unknown-linux-gnu )

everything else (except the kernel) builds on this system for powerpc-unknown-linux-gnu or just powerpc-unknown-linux.

Passing --build=powerpc-unknown-linux to GHC's ./configure solves the problem both for 6.6.1 and (as far as I have tried) for 6.8.

I am not familiar with the autotools, but even GHC finds, in config.log:

Using built-in specs. Target: powerpc-unknown-linux-gnu

Perhaps it is just a matter of actually using this to achieve what I achieved manually by passing --build=powerpc-unknown-linux.

It may even be an autotools problem: At least readline-5.2, which reports the same target, still has only powerpc64 in config.status.

In gentoo, I believe the correct settings are achieved by /usr/portage/profiles/default-linux/ppc/ppc64/2007.0/32bit-userland/make.defaults

[guest]

Gentoo build environment component /usr/portage/profiles/default-linux/ppc/ppc64/2007.0/32bit-userland/make.defaults

[igloo]

I'm not entirely sure we're doing anything wrong here. If you were to compile under linux32 then I expect it would work, e.g. on an amd64 machine in a 32bit chroot:

$ uname -m    
x86_64
$ linux32 bash
$ uname -m
i686
$

I'm not an expert on this, so I don't know if we are meant to somehow detect what is going on when linux32 is not used.

[guest]

man linux32 redirects me to man setarch and documents that the only thing it does is changing the output of uname -m, in my case from ppc64 to ppc.

man uname says "print the machine hardware name" for -m, so this seems to me not quite the right test to figure out the userland on hardware that supports several.

As I pointed out in a previous comment, GHC's config.log contains

Using built-in specs. Target: powerpc-unknown-linux-gnu 

I am no autotools expert, but I would expect that there should be some way to actually use this.

For me personally, the issue is solved with the --build=powerpc-unknown-linux flag, and if you put either that or the linux32 hint (assuming that works) into the INSTALL file, this should take care of the problem for most users.

But ideally, a GHC release should not fail to build out of the box on one of its own nightly test build machines...

[simonmar]

We're not entirely sure what/where the problem is here. Could you please attach the whole config.log generated by GHC's configure script?

[guest]

config.log for ./configure on ppc64 with 32bit userland without any precautions, WK

[guest]

config.log for ./configure --build=powerpc-unknown-linux-gnu, WK

[guest]

config.log for linux32 ./configure on ppc64 with 32bit userland, WK

[guest]

The lines

Using built-in specs.
Target: powerpc-unknown-linux-gnu

in the out-of-the-box config.log come after

configure:3236: gcc -v </dev/null >&5

--- perhaps it is worth while making sure that GHC does not try to target a different machine than the gcc it uses? ;-)

There amy already be something in the direction:

configure:3357: checking whether we are cross compiling
configure:3359: result: no

but obviously it does not catch this case.

Wolfram

[simonmar]

Replying to guest:

This clearly isn't a serious problem, if it's a problem at all. uname -m on your system claims ppc64, so that's what GHC uses as its target by default, and you can use --build to override it. I bet gcc does the same thing. Prefixing the configure with linux32 also overrides the default.

You point out that there is an inconsistency that GHC's configure could have detected: gcc's target is different from the default target that we chose. Even if we detected that, I suspect the right behaviour is to fail with a message suggesting the use of --build. I'll leave the bug open but at a low priority.

[guest]

This clearly isn't a serious problem

agreed.

uname -m on your system claims ppc64, so that's what GHC uses as its target by default

I would argue that uname -m is the the wrong source of information for determining the target. Since GHC produces assembly code (either directly or via C) that is intended to link against at least certain libraries, it should take care that it is compatible with those.

For example, compiling some floating-point primitives cbits together with some dummy main() will link against libm; then one could use ldd to find out which libm is used, and file to find out more about that:

 $ file -L /lib/libm.so.6
/lib/libm.so.6: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.6.9, stripped

Probably something in binutils gives a more precise interface to the information we need here --- the best I could find quickly is readelf:

 $ readelf -h /lib/libm.so.6
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           PowerPC
  Version:                           0x1
  Entry point address:               0xde50
  Start of program headers:          52 (bytes into file)
  Start of section headers:          697360 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         10
  Size of section headers:           40 (bytes)
  Number of section headers:         31
  Section header string table index: 30

Wolfram

[simonmar]

I don't think we're likely to do anything here.

[simonmar]

Re-opening. It seems there are Linux/x86-64 installations that have the same behaviour: uname -m reports x86-64, but gcc and tools generate x86 binaries.

Plan: detect when this has happened and bail out in configure, perhaps suggesting the use of linux32.

[wkahl]

Since linux32 only acts on uname -m, and uname -m is not the right question to ask anyway, I would rather suggest chosing an appropriate --build setting — this way at least the end user uses an appropriate interface.

[simonmar]

We want to do the right thing here, but I'm not sure it's as simple as you say.

If there's a mismatch between uname -m and the kind of binaries that gcc produces, then who's to say which one is "right"? You might have forgotten to point the build at the correct gcc, or you might have forgotten to use linux32. We could guess that you wanted a 32-bit build and do that, but we might be wrong. The best we can do is spot the inconsistency and ask the user to resolve it.

[igloo]

It looks like some normalisation would be necessary:

ian@matrix:~$ uname -m
i686
ian@matrix:~$ gcc -dumpmachine
i486-linux-gnu

$ uname -m
i686
$ gcc -dumpmachine
mingw32

I'm moving this to the 6.10 branch, as I don't think there's much advantage to doing this in 6.8.3, but there is the potential for the build to abort in some cases that are OK but that we didn't test.

[wkahl]

For ghc-6.10.0.20081007 on ppc64 with 32-bit userland, linux32 is still necessary. Here I get:

 $ uname -m
ppc64
 $ gcc -dumpmachine
powerpc-unknown-linux-gnu

[simonmar]

Highly relevant message on the autoconf mailing list:  http://www.mail-archive.com/autoconf@gnu.org/msg12932.html

[igloo]

We now get the platform from the bootstrapping compiler's ghc +RTS --info output.