[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Diego Biurrun]

On Wed, Sep 20, 2006 at 07:06:54PM -0700, Roman Shaposhnick wrote:
> 
> 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.

Seconded (or thirded, rather).

Diego