search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.83k stars 11.46k forks source link

GCC Toolchain discovery on Solaris #24980

Open llvmbot opened 9 years ago

llvmbot commented 9 years ago
Bugzilla Link 24606
Version trunk
OS Solaris
Attachments proposed patch
Reporter LLVM Bugzilla Contributor
CC @Theodor,@rorth

Extended Description

This is a placeholder bug for a patch submission I will do very shortly.

Summary:

The discovery of the GCC Toolchain location in Solaris is currently not optimal. It relies on hardcoded paths, and these hardcoded paths are, by now, obsolete. The result is that, for many recent Solaris versions, this does not really work.

I will provide a patch which enables the dynamic discovery of a GCC installation in Solaris 11 or higher, based on our GCC Solaris installation conventions.

We have a number of clang and llvm patches for Solaris, and we have every intention of contributing them to the project. This is just the first of several bugs with follow-up patches that I will be filing.

Theodor commented 7 years ago

Bug llvm/llvm-project#19740 has been marked as a duplicate of this bug.

llvmbot commented 7 years ago

Take a look at the patches for LLVM 3.8.1 that are currently published by Oracle at GitHub:

https://github.com/oracle/solaris-userland/tree/master/components/llvm/

There's a directory in there named "patches". This is the LLVM (3.8.1) that currently exists in Solaris. There are many patches.

GCC toolchain discovery worked 100% correctly for LLVM 3.8.1 and Solaris 12 and 11.

Given that now we're talking about LLVM 5.0, things might have changed in tools/clang/lib/Driver/, tools/clang/lib/Basic/ and tools/clang/lib/Frontend/.

So my patches from 3.8.1 might need to be adjusted to the new clang.

Theodor commented 7 years ago

Examples of how current Solaris gcc toolchain discovery is dysfunctional (on Solaris 11 SPARC/x86, clang freshly built from the recent trunk):

  1. on x86 it is completely dead

] bin/clang -v clang version 6.0.0 (repos/clang d05132d21feabe6647727a6b028ec1b424ae1953) (repos/llvm bcf10065bb5574d7a29907b5a99af52edd10dacc) Target: i386-pc-solaris2.11 Thread model: posix InstalledDir: .../llvm-build/intel-50/bin Found candidate GCC installation: /usr/gcc/4.8 Selected GCC installation: /usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11 ]

Note how it selected sparc triple instead of x86. Even with explicit --gcc-toolchain it fails to find headers and runtime .o's:

] touch test.c ] bin/clang -v --gcc-toolchain=/usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11 test.c clang version 6.0.0 (repos/clang d05132d21feabe6647727a6b028ec1b424ae1953) (repos/llvm bcf10065bb5574d7a29907b5a99af52edd10dacc) Target: i386-pc-solaris2.11 Thread model: posix InstalledDir: .../llvm-build/intel-50/bin ".../llvm-build/intel-50/bin/clang-5.0" -cc1 -triple i386-pc-solaris2.11 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir .../llvm-build/intel-50/lib/clang/6.0.0 -fdebug-compilation-dir .../llvm-build/intel-50 -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fobjc-runtime=gcc -fdiagnostics-show-option -o /var/tmp/test-d5c222.o -x c test.c clang -cc1 version 6.0.0 based upon LLVM 6.0.0git-bcf1006 default target i386-pc-solaris2.11 ignoring nonexistent directory "/usr/local/include"

include "..." search starts here:

include <...> search starts here:

.../llvm-build/intel-50/lib/clang/6.0.0/include /usr/include End of search list. "/usr/bin/ld" -C -e _start -Bdynamic --dynamic-linker /usr/lib/ld.so.1 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o crtbegin.o -L.../llvm-build/intel-50/bin -L.../llvm-build/intel-50/bin/../lib -L/usr/lib/ /var/tmp/test-d5c222.o -lgcc_s -lc -lgcc -lm crtend.o /usr/lib/crtn.o ld: fatal: file crtbegin.o: open failed: No such file or directory ld: fatal: library -lgcc: not found ld: fatal: file crtend.o: open failed: No such file or directory clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) ]

  1. on SPARC it fails to handle m32/m64 bi-arch gcc toolchain setup typical for Solaris

] bin/clang test.c -m64 ld: fatal: file /usr/lib/sparcv9/crti.o: wrong ELF class: ELFCLASS64 ld: fatal: file /usr/lib/sparcv9/values-Xa.o: wrong ELF class: ELFCLASS64 ld: fatal: file /var/tmp/test-8b2811.o: wrong ELF class: ELFCLASS64 ld: fatal: file /usr/lib/sparcv9/crtn.o: wrong ELF class: ELFCLASS64 clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) ]

This happens because clang fails to apply arch-specific suffix to crtbegin/crtend.o path and selects 32-bit version of these.

llvmbot commented 7 years ago

I can't comment on the technical merits of any of your proposals simply because you haven't proposed anything.

Did you provide a new and improved patch that addressed your own concerns?

No, you did not. The only thing you are doing is marking bugs as invalid. And the real reason you are doing that is because of what I have already stated in my previous comment about open source competitors to the commercial Studio compiler.

By the way, the real reason why I couldn't get patches accepted is because Oracle internal rules did not allow me to work on trunk. We could only work with numbered releases, and no-one in Oracle management had any interest in making working in trunk possible.

Theodor commented 7 years ago

This is the Sun compiler team back

yes, this is. Though I would prefer using a different forum for discussing non-technical matters.

Nothing that you wrote here is anywhere remotely true.

I dont believe anybody will question my statement that: "this patch is huge ... addressing many unrelated issues at once"

I'm pretty sure that the sheer size of this patch makes probability of it being accepted by LLVM community pretty slim.

Thus in order to make progress here the only practical approach is to split the issues. Since gcc toolchain detection is a cornerstone for this activity, I suggest to keep tracking it here.

Feel free to comment on technical viability of this approach.

llvmbot commented 7 years ago

Nothing that you wrote here is anywhere remotely true.

After not having contributed anything to clang or LLVM you suddenly decide to declare a bunch of clang Solaris unnecessary.

With this patch, and the subsequent one that I wrote for 3.8.1, GCC toolchain discovery works 100% correctly in Solaris.

This is the Sun compiler team back to playing their old dirty tricks.

They don't want a working clang in Solaris because clang is a competitor to their commercial compiler product that cannot compete on features. The only way of keeping the Studio compilers viable is by crippling clang and making it as broken and unusable in Solaris as possible. This was and is their official position on any kind of competitor compiler product, including clang and GCC.

Theodor commented 7 years ago

While it is very true that gcc toolchain discovery on Solaris is waay far from optimal (it fails when multiple toolchains are installed, it fails to resolve multilib configuration properly etc etc), this particular patch is huge and unwieldy, addressing many unrelated issues at once.

(besides gcc toolchain discovery itself it addresses -march/-mcpu/-mtune handling, Solaris version detection, macro settings, linker args handling etc etc)

This bug is better be left tracking gcc toolchain discovery functionality itself.

llvmbot commented 9 years ago

assigned to @Theodor