[FFmpeg-trac] #1783(undetermined:new): libavutil contains file with the same name as a system header
FFmpeg
trac at avcodec.org
Thu Oct 4 00:17:59 CEST 2012
#1783: libavutil contains file with the same name as a system header
-------------------------------------+-------------------------------------
Reporter: obucinac | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: unspecified | undetermined
Keywords: | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by dlongest):
Well this is partially an Android build system issue, however it is an
issue that could easily pop up somewhere else.
The Android NDK allows you to set up Android specific Makefiles (usually
titled Android.mk or Application.mk) in order to simplify development,
their build tools automatically set up include directories, handle
dependencies, handle proper linking, and more. Part of the process causes
the GCC call to have an extra -I flag for the directory the c/cpp file is
located. This causes a file like "parseutils.c" to be compiled with
something like the following.
{{{
arm-linux-androideabi-gcc -MMD -MP -MF ./obj/local/armeabi-v7a/objs-
debug/avutil/parseutils.o.d -Ijni/ffmpeg/libavutil -c
jni/ffmpeg/libavutil/parseutils.c -o ./obj/local/armeabi-v7a/objs-
debug/avutil/parseutils.o
}}}
Since parseutils.c (as well as parseutils.h) includes <time.h>, the
compiler will first find the time.h from the avutil folder since it has
been added as an include path by Android's build system. This prevents the
compiler from finding time.h in the ANSI C library. While at the core this
is really a fault of Android's build system, it is much more easily fixed
by renaming a file compared to creating a new build system specifically
for FFmpeg on Android or any other build systems that set include
directories in this fashion.
Replying to [comment:4 cehoyos]:
> Replying to [comment:3 dlongest]:
> > Correct me if I am wrong, but giving a header the same file name as
one in the ANSI C standards may not fall under best practices anyways.
Possibly "avtime.h" would be a better fit in this case.
> So if I understand you correctly you suggest that instead of you using
the correct "#include <libavutil/avutil.h> (or whatever the use case might
be), we should break API?
>
> Or to try it differently:
> Please provide the C program and (the Makefile or the gcc command line
that fail). As you found out, neither the Makefile nor the gcc command
line must contain "-I/usr/include/libavutil".
>
> Or am I missing something?
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1783#comment:5>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list