[FFmpeg-devel] [PATCH] broken build with --disable-optimizations

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Mon, Jan 18, 2010 at 02:01:11PM +0000, M?ns Rullg?rd wrote:
>> Jai Menon <jmenon86 at gmail.com> writes:
>> 
>> > On Sun, Jan 17, 2010 at 10:06:17PM +0100, Michael Niedermayer wrote:
>> >> On Mon, Jan 18, 2010 at 01:11:40AM +0530, Jai Menon wrote:
>> >> > Hi,
>> >> > 
>> >> > Attached patch fixes it. This probably isn't correct and is
>> >> > just meant to be an indicator of what the issue is.
>> >> 
>> >> Could you show me the error message with which it fails?
>> >
>> > here you go :
>> >
>> > /home/jai/ffbuild/libavcodec/libavcodec.a(h264.o): In function
>> > `decode_significance_8x8_x86':
>> > /home/jai/ffmpeg/libavcodec/x86/h264_i386.h:97: undefined reference to
>> > `last_coeff_flag_offset_8x8'
>> 
>> The problem is all those non-inline functions in h264*.h. 
>
>> There is absolutely no sense whatsoever in having a non-inline
>> function in a header file.
>
> There is a sense, some things like CABAC are constants that way but
> would not if its in a C file. inlining OTOH may or may not be good,
> its independant

I see your point.  However, you could still put both versions of the
function in a .c file, perhaps by #including a template.h with
different definitions.

>> Either the function should be inlined or it should not.
>> In the former case it should be marked inline explicitly, in the
>> latter it should be in a .c file.  Having multiple copies of
>> non-inline functions in the object code is obviously a bad thing.
>> 
>> Michael, if this is a work in progress and you're experimenting with
>> inlining, say so and that's fine.  If you do not intend for these
>> functions to be inlined, please move them to .c files.
>
> someone has to benchmark if static, static inline or static in .c is faster
> for each function. If someone does iam perfectly fine with these functions
> being changed to their fastes variant.
> If someone wants they can also temporary mark all as static inline until
> someone has time to benchmark them.
>
> besides the static function this time is in h264_i386.h and that was
> there since a long time and not commited by me, actually i was unaware
> that it was non inline until now.
>
> and jais compiler is broken if it does not remove unused static functions

There is no such requirement in the C standard, so technically the
compiler is not broken at all, just not optimising very well (at the
request of the user this time).

-- 
M?ns Rullg?rd
mans at mansr.com