[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Måns Rullgård]

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.

> It's a common enough syndrome. When there was no direct TLS support in
> Linux pthreads, writing about it only got you 'That would be very bad
> for performance, because of TLB flushing!' (or the ozone layer, or
> whatever). Now 2.6 and NPTL *have* direct TLS support with assist from
> gcc, and wow, now TLS is cool!

I have used TLS *once*, for one single variable, and that was only to
work around shortcomings in the API of a library, and then only in an
error reporting callback.

-- 
M?ns Rullg?rd
mru at inprovide.com