[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Rich Felker]

On Tue, Sep 19, 2006 at 07:43:58PM +0200, Diego 'Flameeyes' Petten? wrote:
> On Tuesday 19 September 2006 18:40, Rich Felker wrote:
> > Arrg, why does flameeyes keep pushing these OS-specific hacks?
> This is NOT os-specific, this works on */Linux, *BSD, Darwin, ...

It is OS-specific. The "OS" in question is the GNU binutils. I doubt
it works on Darwin.

> > but since it's GNU brain damage everyone 
> > keeps entertaining his broken solutions...
> I don't see how ensuring the exported interface can be considered braindamage. 

The GNU brain damage is the fact that ELF sucks and that the GNU
people pushed it on all the other free unices. Read the history if
you're not aware of it.

> A pain to do the first time, maybe, but not an error. By ensuring a proper 
> interface is provided, you're also making it safe for other projects to use 
> FFmpeg without using symbols that might change behaviour, format or who knows 
> what else.

The way you do this is by DOCUMENTING the interface, not by
enforcement through vile extensions to the language.

> > If shared libs are this broken then *gasp* don't use shared libs!
> Usage of static libraries to link FFmpeg is sub-optimal for at least two 
> projects currently using FFmpeg (xine and VLC), that both use a plugins-based 
> architecture.

It's their fault for using a stupid architecture. Dynamic linking
inherently uses more memory and runs slower.

> In addition to that, statically linking FFmpeg will become an 
> extra burden for package maintainers, and a problem from a security point of 
> view (because you'd need to identify all the programs linking to FFmpeg and 
> rebuild them every time a vulnerability is discovered).

Too bad.

> The burden of using explicit visibility is only initial, because there are all 
> the symbols to sort out, but after that the work is done, and internal 
> symbols can be changed without caring about the external ABI (if they are not 
> exported, they are no more part of ABI).

The burden is making the program less portable and more polluted with
ugly OS-specific hacks. I'm sick of your Linux-kiddie mindset. The
world is not a GNU/Linux/ELF.

> Plus, you get the interesting upside of having better performance with shared 
> libraries, that I still find useful even if I know lot of people disagree 
> with the usage of shared libraries in the first place.

-Bsymbolic will give the same benefit. Using static linking will give
even more benefit.

Rich