On SUSE distributions for 32-bit PowerPC, gcc is configured
as a 64-bit compiler using the GNU triplet "powerpc64-suse-linux",
but invoked with "-m32" by default. Thus, the correct GNU triplet
for 32-bit PowerPC SUSE distributions is "powerpc64-suse-linux"
and not "powerpc-suse-linux".
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
Yes, this is a stupid situation to be in, but 32-bit PowerPC on SUSE really does use /usr/lib/gcc/powerpc64-suse-linux:
root@redpanda:/var/tmp/build-root/openSUSE_Factory_PowerPC-ppc/usr/lib/gcc/powerpc64-suse-linux/8# file crtbegin.o crtbegin.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped
I would however argue that we should keep powerpc-suse-linux; in theory there's nothing stopping a SUSE derivative (or SUSE themselves if they want to do a mass-rebuild) from moving everything to powerpc-suse-linux and improving everyone's sanity.
This should also have a comment explaining why there's a 64-bit triple here for future readers.
Well, I agree on the comment to clarify why it has to be powerpc64-suse-linux, but I'm not sure whether anyone will ever start a SUSE derivative for 32-bit PowerPC, then fix the path in SUSE's gcc and then do a mass-rebuild. I think the probability is pretty low.
A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation:
- We seem to be changing the set of aliases here, but what happens if someone actually explicitly specifies --target=powerpc-suse-linux?
- Do we need to change anything about include paths?
- Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be powerpc-suse-linux? powerpc64-suse-linux?
- Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?
- Can you please add a test case and a patch with full context before this patch can go any further?
This is just the name of GCCDIST that is adjusted.
- Do we need to change anything about include paths?
No.
On an openSUSE machine on ppc, we have:
:/usr # ls -l /usr/lib/gcc/ total 0 drwxr-xr-x 3 root root 15 Nov 19 23:27 powerpc64-suse-linux :/usr # ls -dl /usr/power* drwxr-xr-x 5 root root 43 May 25 2018 /usr/powerpc-suse-linux :/usr #
- Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be powerpc-suse-linux? powerpc64-suse-linux?
I have to verify this.
- Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?
No. There are separate compiler packages for ppc64 and ppc.
- Can you please add a test case and a patch with full context before this patch can go any further?
Not sure what the proper test would be.
On a sidenote, the spec file for gcc8 in openSUSE has:
%define HOST_ARCH %(echo %{_host_cpu} | sed -e "s/i.86/i586/;s/ppc/powerpc/;s/sparc64.*/sparc64/;s/sparcv.*/sparc/;") %ifarch ppc %define GCCDIST powerpc64-suse-linux %else %ifarch %sparc %define GCCDIST sparc64-suse-linux %else %ifarch %arm %define GCCDIST %{HOST_ARCH}-suse-linux-gnueabi %else %define GCCDIST %{HOST_ARCH}-suse-linux %endif %endif %endif
See: https://build.opensuse.org/package/view_file/devel:gcc/gcc8/gcc8.spec?expand=1
So, it's explicitly overriding GCCDIST on ppc to be powerpc64-suse-linux.
Do you plan to follow-up on these questions and comments?
At least the full context is needed and for the test case, I imagine it can be similar to other driver test cases. I imagine tools/clang/test/Driver/linux-ld.c can be augmented with this?
Well, I don't really know what to add here. The GCCDIST path on 32-bit PowerPC SUSE distributions has always been "powerpc64-suse-linux" according to SUSE's gcc maintainer Richard Biener and my patch just fixes that.
We're already using this patch in openSUSE without any issues: https://build.opensuse.org/package/view_file/devel:tools:compiler/llvm7/clang-fix-powerpc-triplet.patch?expand=1
Sorry for warming this up again, but it would be nice to get rid of this patch in openSUSE.
So I've had a look at the gcc packages on PowerPC and where they put their stuff.
on ppc | on ppc64 | |
32-bit gcc | gcc9 uses /usr/lib/gcc/powerpc64-suse-linux/9/ | gcc9-32bit uses /usr/lib64/gcc/powerpc64-suse-linux/9/32/ |
64-bit gcc | gcc9-64bit uses /usr/lib/gcc/powerpc64-suse-linux/9/64/ | gcc9 uses /usr/lib64/gcc/powerpc64-suse-linux/9/ |
For comparison, on x86:
on i586 | on x86_64 | |
32-bit gcc | gcc9 uses /usr/lib/gcc/i586-suse-linux/9/ | gcc9-32bit uses /usr/lib64/gcc/x86_64-suse-linux/9/32/ |
64-bit gcc | not available | gcc9 uses /usr/lib64/gcc/x86_64-suse-linux/9/ |
So on x86 we do indeed have different triples, but there is no conflict between 32-bit and 64-bit default libraries either way, because the alternative arch always sits in a subdirectory.
There is no such image currently, and the repositories are empty, so given the waning popularity of 32-bit PowerPC that's a valid assumption, I guess. I think that 32-bit binaries are only built to be available on 64-bit systems.
This one is a bit weird, why /usr/powerpc-suse-linux suddenly? And is that going to be a problem?
I see that packages that use Clang compile fine on ppc, e.g. include-what-you-use, but I'm still wondering why this works.
- Can you please add a test case and a patch with full context before this patch can go any further?
Not sure what the proper test would be.
I guess something like the test for D32347: add a mock directory tree, and test that everything is set up correctly.
This change does not affect the Clang triple, that is and will be powerpc-unknown-linux-gnu. It's just about where Clang looks for the GCC toolchain.
- Do we need to change anything about include paths?
Most of them should be independent of the GCC triple, except for /usr/include/c++/<gcc-ver>/<gcc-triple>. That should also work with this change.
- Will this change not affect 64-bit PPC SUSE? Namely will the default libraries on actual 64-bit PPC SUSE big endian systems now be 32-bit libraries?
No, the 32-bit libraries on a 64-bit system sit in a /32 subfolder.