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

[Ryan Schmidt]

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.