On Dec 28, 2013, at 0:36 , Ryan Schmidt <[email protected]> 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.
>>> 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 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), and now nobody can rely on a simple test
for 'gcc' or 'llvm-gcc' actually returning what you'd expect. 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.
-landonf
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
