[Ffmpeg-devel] libavutil conflict with system headers on Darwin
Mon Dec 4 13:40:50 CET 2006
Diego Biurrun said:
> On Sun, Dec 03, 2006 at 05:27:55PM +0100, Reimar D?ffinger wrote:
>> > > It is usually reasonable to include system headers before ffmpeg
>> > > headers, but that's not enough to avoid the problem. Other non-system
>> > > headers besides ffmpeg ones can also use __attribute__((always_inline)),
>> > > and it's not reasonable to require that ffmpeg headers must be included
>> > > after those. It would be impossible to include headers from two projects
>> > > with such "must appear last" requirements.
>> > as these arent supposed to be vissible to the outside you can never have a
>> > problem with headers from 2 projects ...
>> Unfortunately always_inline currently is visible outside. Probably a bad idea in
>> looking back.
>> Though I find this define a bit weird anyway, since is named the same
>> way as one of its "components":
>> # define always_inline __attribute__((always_inline)) inline
>> In addition it is inconsistent, e.g.:
>> # define attribute_used __attribute__((used))
>> so attribute_always_inline would be more consistent (although
>> always_inline is not only an attribute it also includes inline).
> So my next suggestion is to rename it to
> which is both more consistent and should avoid the name clash we are
> currently suffering from. Is that a workable solution?
That's not really any more consistent. The expansion of attribute_inline
includes the regular 'inline' keyword as well as __attribute__((always_inline)).
Before changing anything, I'd suggest investigating whether a simple reordering
of #include directives would get around the problem. Are these macros visible
to applications using our headers? Should they be?
mru at inprovide.com
More information about the ffmpeg-devel