On Dec 28, 2013, at 13:48, Landon Fuller wrote:
> On Dec 28, 2013, at 0:36 , Ryan Schmidt wrote:
>
>> If you have reason to believe that *only* llvm-gcc — not clang, not gcc —
>> will work, then ok, whitelist only llvm-gcc. That would be unusual, but
>> maybe openjdk is unusual in its compiler needs; I don’t know.
>
> With a mixture of a full runtime JIT compiler coupled with an assembly
> template-based interpreter (and on 32-bit systems reliance on ugly features
> like -mstackrealign), there's a lot of room for things to go very subtly
> wrong in ways that may not be immediately obvious to anyone. Targeting a
> consistent toolchain eliminates uncertainty and ensures that any failures --
> whether they're due to bugs in OpenJDK, such as invalid ABI constructs in the
> JIT-generated and hand-written assembly templates, or simply due to compiler
> bugs -- will be *consistent* across builds.
>
> Since Oracle is also currently using LLVM-GCC, targeting a single revision
> also leverages any work they've done in testing, especially around toolchain
> interaction issues.
Ok. Sounds reasonable.
>>>> MacPorts will pick the next-best compiler, which will be llvm-gcc42,
>>>> either the version provided by Xcode or the one provided by MacPorts,
>>>> depending on what’s available. You can then use the variables
>>>> ${configure.cc}, ${configure.cxx}, etc. where you need them.
>>>
>>> Will this actually work with llvm-gcc?
>>
>> Yes, it will work with all compiler names that MacPorts recognizes. See
>> portconfigure.tcl.
>
> It appears to work by luck; as per Lawrence Velázquez's e-mail,
> "llvm-gcc-4.2" works only because Apple doesn't vend a version-suffixed clang
> binary with the 'llvm-gcc-4.2' name. If we used 'llvm-gcc' instead of
> 'llvm-gcc-4.2', for example, the implementation would, according to my
> reading, find Xcode's not-actually-llvm-gcc binary in /usr/bin.
>
> Indeed, if 'gcc' is specified (compiler.whitelist gcc), portconfigure.tcl
> *does* return the faux system GCC:
> DEBUG: Assembled command: 'cd
> "/opt/local/var/macports/build/.../openjdk7/work/openjdk" && /usr/bin/make
> CC="/usr/bin/gcc" CXX="/usr/bin/g++" …
I don’t know that this is working by change; rather, as far as I can tell, the
blacklist and whitelist work on the very specific compiler names that MacPorts
recognizes:
https://trac.macports.org/browser/trunk/base/src/port1.0/portconfigure.tcl?rev=113062#L209
The fact that that list includes the compiler names “gcc” and “cc” is something
I still consider a bug. I’ve mentioned that before. I hope nobody uses these
compiler names. I wish we would remove them from MacPorts, because they are not
deterministic, as you pointed out and as it says in the wiki:
https://trac.macports.org/wiki/UsingTheRightCompiler
>> I am not Apple, but clang *is* more or less compatible with most of what gcc
>> does. And since Apple decided to no longer ship gcc or llvm-gcc but only
>> clang, the two choices were: make “gcc" a symlink to clang, or provide no
>> "gcc" at all. They chose the former, and I think it was an ok choice; had
>> they chosen the latter, I can imagine a *lot* of software not being able to
>> build out of the box, since a lot of software assumes the compiler is “gcc”.
>
> I say this as someone happy to see GCC 4.2 gone -- the problem is that "more
> or less compatible" is not good enough for anyone that cares about the
> compiler selection (such as portconfigure.tcl),
which is why portconfigure.tcl always uses a specific compiler by its absolute
path, not the “cc” or “gcc” symlinks.
> and now nobody can rely on a simple test for 'gcc' or 'llvm-gcc' actually
> returning what you'd expect.
Within MacPorts, nobody should be attempting such a test. Use the selected
compiler, whose absolute path is in the variable ${configure.cc}.
> Apple could have continued to ship GCC and LLVM-GCC, stopped shipping
> anything named 'gcc' and 'llvm-gcc' outright, or even printed 'deprecation'
> warnings whenever invoking the gcc compiler-compiler front-end.
I would guess that not shipping anything named “gcc” would have broken a lot
more software than making “gcc” a symlink to clang did.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
