Open llvmbot opened 9 years ago
Bug llvm/llvm-project#19740 has been marked as a duplicate of this bug.
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.
Examples of how current Solaris gcc toolchain discovery is dysfunctional (on Solaris 11 SPARC/x86, clang freshly built from the recent trunk):
] 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"
.../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) ]
] 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.
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.
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.
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.
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.
assigned to @Theodor
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.