On 2012-12-25 03:55, Matthew Rezny wrote:
The Ports and Clang wiki page has x264 listed as a port with build problems,
but has Y for the USE_GCC=any workaround. The last commit on the port, over 3
months ago, has a contradictory message, noting the workaround is insufficient
and thus is only a temporary fix.
The "configure glop" is actually very bad at detecting clang, it only
has a hardcoded gcc setting. :-)
Somehow, the USE_GCC=any setting destroys any manually set ${CC} in the
environment.
I am running 9.1-RELEASE/amd64 built WITH_CLANG_IS_CC and WITHOUT_GCC. I hit
the deficiency in the workaround today while building ports.
I took the default port options, except to disable PGO as I expected that would be GCC
specific. First attempt, configure fails with no working C compiler, config.log shows it
tries to call "gcc" which does not exist because the port did not trigger any
gcc from ports.
Second attempt, turn on GCC4.4+ option, clean and make again. Same failure,
config.log is identical. Huh, why didn't it even try to build some GCC from
ports? Looking at the Makefile I notice the blanket USE_GCC=any and later the
conditional USE_GCC?=4.4+. So the workaround appears to smash the port's
GCC4.4+ option and thus it could never actually use any GCC from ports with
this workaround in place. The workaround is now the culprit in the brokenness
when WITHOUT_GCC is used.
Third attempt, remove the offending USE_GCC=any line from the Makefile, turn
off the GCC4.4+ option in the port, clean and make again. Success! The port
builds clean with Clang, no errors or warnings except an ignored GCC specific
option. I have not tested use of the port, that has to wait for others to
finish building so I have some way to do so.
Yes, that is what works for me too. If you turn off the PGO option, it
builds just fine with clang 3.1 (in stable/9) and clang 3.2 (in head),
although it does complain about a few unsupported command line options.
The immediate question is, what was the original error that mandated the
workaround and does that error still occur with current version of Clang? If
the latter is no, can we get rid of the temporary workaround?
Unfortunately the original build logs which pointed out the error have
been lost, apparently due to the security incident.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
