[MacPorts] #48938: ffmpeg build failure on 10.6
MacPorts
noreply at macports.org
Thu Sep 24 11:01:27 PDT 2015
#48938: ffmpeg build failure on 10.6
--------------------------------+-------------------------
Reporter: chilli.namesake@… | Owner: devans@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.3.3
Resolution: | Keywords: snowleopard
Port: ffmpeg |
--------------------------------+-------------------------
Comment (by devans@…):
Replying to [comment:2 ryandesign@…]:
> Snow Leopard is still supported to the extent that if something isn't
working we will try to take a look at it if we can. But if the developers
have made changes that make a software package require a newer version of
OS X, then there's not much we can do about that. I don't know yet if
that's the case here though or not.
Ryan ---
Thanks for your help in spotting these build errors. As you know, I don't
have a 10.6 machine available to test ffmpeg on this platform so I rely on
help from those who do to fix this type of error. This is particularly
true since we no longer have a working 10.6 buildbot.
So for this port, I have to take the position that problems that are
specific to older platforms will not be addressed unless someone with the
required hardware/software to reproduce the problem can post a specific
fix/patch that does not effect the build on more recent platforms.
Since ffmpeg 2.8 builds correctly on at least 10.8 and newer, I have to
question what the difference is between those platforms and 10.6. The
most obvious difference is, of course, the compiler so I wonder if using a
newer version of clang on 10.6 might fix these problems without the need
for the various patches that you propose below. Is this feasible and if
so have you tried it?
See my comments below on the specific failures.
>
> -----
>
> The log shows that the first error is:
>
> {{{
> :info:build libavfilter/avf_showcqt.c:38:10: error: #include expects
"FILENAME" or <FILENAME>
> }}}
>
> This type of error is repeated a few times.
>
> Lines 36-39 of libavfilter/avf_showcqt.c are:
>
> {{{
> #if CONFIG_LIBFREETYPE
> #include <ft2build.h>
> #include FT_FREETYPE_H
> #endif
> }}}
>
> This means that `CONFIG_LIBFREETYPE` is defined (as it should be), but
that `FT_FREETYPE_H` (which should be defined in a file included by
ft2build.h) is not defined. I think this happens because the compiler was
invoked without specifying the directory where ft2build.h can be found
(the argument `-I/opt/local/include/freetype2` is missing) though I don't
understand why we didn't get a "file not found" error. It might be because
this is not a normal compiler invocation, but rather an invocation of the
preprocessor.
>
> This is a bug in ffmpeg (or else a bug in the gcc compiler exposed by
ffmpeg's code, which ffmpeg should work around), reported with a proposed
fix [https://lists.ffmpeg.org/pipermail/ffmpeg-
devel/2015-September/178418.html here] (where it says that the clang
compiler is not affected). This might not be a relevant error, since the
build proceeds past it, but **we should probably apply this patch**.
-----
Comparing the 10.6 build log with the successful one on 10.10 (attached)
shows that the build command for this module does, in fact, include
-I/opt/local/include/freetype2 as one would expect. The implication that
the problem here is with the configuration system possibly compiler
related.
>
> -----
>
> The next error in the log is:
>
> {{{
> :info:build ffplay.c:3217:46: error: missing binary operator before
token "("
> }}}
>
> Line 3217 of ffplay.c is:
>
> {{{
> #if defined(__APPLE__) && SDL_VERSION_ATLEAST(1, 2, 14)
> }}}
>
> This implies that `SDL_VERSION_ATLEAST` is not defined. It should have
been defined in SDL_version.h which is included by SDL.h which is included
by ffplay.c. The reason is the same as above: this is another preprocessor
invocation, and they haven't included the path where the SDL headers are
found. (`-I/opt/local/include/SDL` is missing). The above fix should fix
this as well.
Again the 10.10 build log uses -I/opt/local/include/SDL in the build
command so as you say this seems to be similar to the previous problem.
Why isn't this term included on 10.6?
>
> -----
>
> The next error, and possibly the real problem, begins hundreds of lines
of similar errors:
>
> {{{
> :info:build In file included from /usr/lib/gcc/i686-apple-
darwin10/4.2.1/include/xmmintrin.h:40,
> :info:build from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29,
> :info:build from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
> :info:build from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
> :info:build from
/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,
> :info:build from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,
> :info:build from /:19:
> :info:build /usr/lib/gcc/i686-apple-
darwin10/4.2.1/include/mmintrin.h:67: error: no previous prototype for
‘_mm_empty’
> }}}
>
> We've had a report of that type of error with ffmpeg years ago in #36961
but it was closed without a resolution, and since that was only seen by
two users and was with a now years-old version of ffmpeg that might not be
relevant anymore.
>
> We also had a report of that error with mesa in #46827. In both tickets,
Jeremy suggested removing "`-Werror=missing-prototypes`" from the build
system. **We should try this**.
Possibly but it builds fine with clang on 10.8+. Looks to be due to a
10.6 gcc C library problem.
At any rate, would appreciate it if you could try building with MacPorts
clang and see if that works. If not we need to explore this further and
come up with a specific fix with a minimum of patches that works on 10.6
without breaking the build on more recent platforms. As usual any fixes
that appear to address errors in ffmpeg itself should be forwarded upstrem
to the ffmpeg developers.
Thanks again for your help on these older platforms.
--
Ticket URL: <https://trac.macports.org/ticket/48938#comment:7>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list