[FFmpeg-devel] Why 'You can only build one library type at once on MinGW'?

[Uoti Urpala]

On Sat, 2007-05-12 at 23:51 -0400, Rich Felker wrote:
> > No, I mean a different DSO.  If the compiler knows a global variable is
> > going to be located in the same DSO, it can emit a PIC sequence to access
> > it that just involves an extra register to hold the base address.  If the
> > compiler does not know if the variable will come for the same DSO or not,
> > it will emit a slower sequence with an extra indirection.
> 
> And a _C_ compiler cannot know. A compiler for a proprietary C-like
> GNU language which is not C can of course know...

A compiler that would have absolutely nothing beyond the minimum
requirements of the C standard would be pretty useless. Creating PIC
code at all is not covered by the standard. When a compiler does support
creating PIC code for libraries it makes perfect sense to have features
controlling visibility. That does not turn it into "a proprietary C-like
language".

You frequently make this same kind of fallacious argument in your rants:
that a program having or using some functionality beyond the minimum
required by some standard is automatically evil. You don't seem to
understand how most standardization happens. More often than not, first
there are implementations and then later a standard is created. First
there were C compilers, then later a C standard. Now there are
visibility implementations. Most likely ways to specify visibility will
be included in some standard later. For now you can define macros and
then later change their definitions from compiler-specific values to
standardized ones when those are available.