[114733] users/landonf/openjdk7/dports/java/openjdk6/Portfile

[Landon Fuller]

On Dec 28, 2013, at 0:36 , Ryan Schmidt <ryandesign at macports.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20131228/35152a65/attachment.sig>