Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Jan 2021 21:50:17 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 252720] powerpc64 gcc toolchain thinks it is little-endian
Message-ID:  <bug-252720-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252720

            Bug ID: 252720
           Summary: powerpc64 gcc toolchain thinks it is little-endian
           Product: Base System
           Version: 12.1-RELEASE
          Hardware: powerpc
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: jmmv@FreeBSD.org

I recently got a PowerMac G5 (powerpc64 big-endian). I was able to install
12.1-RELEASE successfully (the powerpc64 build; there is no powerpc64le dua=
lity
in 12) on it. I was also able to download the sources for stable/12, do a w=
hole
buildworld, and then an installworld. Everything was flawless!

But after the upgrade to 12.2-STABLE from sources, I am unable to buildworld
again and other things seem randomly broken (pkg cannot load its database a=
ny
longer).

buildworld fails like:

=3D=3D=3D> kerberos5/tools/make-roken (obj,all,install)
objcopy --strip-debug --add-gnu-debuglink=3Dmake-roken.debug  make-roken.fu=
ll
make-roken
objcopy: unsupported e_type
*** [make-roken] Error code 1

I dug around a bit and found that libelf seems to have been compiled for a
little-endian target: when it checks the e_type of the binary, it gets 0x200
when in reality it should be getting a 0x2.

And indeed, after some more poking, it seems that the gcc toolchain that sh=
ips
with 12.1-RELEASE thinks it's targeting a little endian machine:

g5:~> cat test.c=20
#include <stdio.h>

int main(void) {
#if __BYTE_ORDER__ =3D=3D __ORDER_LITTLE_ENDIAN__
    printf("little!\n");
#elif __BYTE_ORDER__ =3D=3D __ORDER_BIG_ENDIAN__
    printf("big!\n");
#else
    printf("what?\n");
#endif
}

With the 12.1-RELEASE toolchain:

g5:~> /usr/bin/cc --version
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

g5:~> /usr/bin/cc test.c && ./a.out
little!

^^^ THIS IS WRONG! ^^^

With the gcc9 compiler installed from pkg:

g5:~> /usr/local/bin/gcc9 --version
gcc9 (FreeBSD Ports Collection) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

g5:~> /usr/local/bin/gcc9 test.c && ./a.out
big!

^^^ THIS IS RIGHT ^^^

After the upgrade to stable/12, the compiler still thinks it's targeting a
little-endian machine.

What's interesting, though, is that the binaries that the compiler produces
_are_ big-endian -- or else nothing would run. However, the __BYTE_ORDER__
macro is wrong.

Any thoughts on where the problem may be and how to get out of this situati=
on?
It looks like I cannot use the base system's compiler to buildworld to upgr=
ade
(or for that matter, to build anything).

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252720-227>