[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Roman Shaposhnick]

Hi

On Wed, 2006-09-20 at 19:34 +0100, M?ns Rullg?rd wrote:
> Michel Bardiaux <mbardiaux at mediaxim.be> writes:
> 
> > Luca Barbato wrote:
> >> Rich Felker wrote:
> >>
> >>> This statement is utterly stupid. Visibility is outside the scope of
> >>> C, just like threads and processes and filesystem structure is outside
> >>> the scope of C, and just like digital storage units are outside the
> >>> scope of SI. A unix ABI standard like SVR4 is totally welcome to
> >>> include such things, but I have no respect for ABI standards because
> >>> all they do is tie you down to a particular implementation and
> >>> facilitate shitty binaryware.
> >> We already pointed out that this feature is available across all the
> >> current and used binary formats.
> >> lu
> >>
> > I tend to agree with Rich here. When visibility of exported symbols
> > was only an issue on MS-W platforms, the usual attitude in th 'nix
> > world was: "That's a very bad dynamic linkage model! Off with his
> > head! The Unix model, with a single symbol space and every symbol
> > visible everywhere, is MUCH simpler hence MUCH better".
> >
> > Now gcc et al. have introduced visibility control in gcc and ld, and
> > all of a sudden it becomes a good idea!
> 
> It is a good idea only when it solves a specific problem.  We don't
> have a problem with symbol visibility, so there is nothing to solve.
> The original problem -fvisibility was meant to solve is caused by
> C++.  The proper solution is of course to not use C++ in the first
> place, but we already knew that.
> 
> Perhaps using the visibility option can have a positive effect on
> performance.  If so, enabling it might be a good idea.  However,
> considering the invasiveness of the patches posted so far, I want to
> see some strong benchmarks in favor of this idea before making these
> changes.  If we're talking about a very small amount, I'd simply
> advise those who need that last drop of performance to use static
> linking.  Besides, that's what they (Rich) seem to be doing already.

  I can not agree more. I would actually like to see a complete problem
statement before the patch in question goes in. So far it seems that
a couple of different needs are being addressed at the same time and
I'm not sure that they are being addressed in the best possible way.

Thanks,
Roman.