Date: Wed, 26 Dec 2012 17:41:19 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Matthew Rezny <mrezny@hexaneinc.com> Cc: freebsd-ports@freebsd.org Subject: Re: multimedia/x264 workaround is broken Message-ID: <50DB28AF.1010207@FreeBSD.org> In-Reply-To: <B00F7B07-CA3D-408E-A626-C39512DEACDD@hexaneinc.com> References: <B00F7B07-CA3D-408E-A626-C39512DEACDD@hexaneinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50DB28AF.1010207>