[FFmpeg-devel] Why 'You can only build one library type at once on MinGW'?
Sun May 13 16:11:33 CEST 2007
On Sun, May 13, 2007 at 08:25:57AM +0300, Uoti Urpala wrote:
> 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.
This is true (because the standard is lax on some technical points
with no practical relevance, i.e. see "at least one conforming
program" stuff) but unrelated to the topic at hand. A compiler that
compiles the C language and NO LANGUAGE EXTENSIONS at all is perfectly
usable for every single real-world application. The only time language
extensions are useful is for seriously performance-intensive tasks,
using inline asm or intrinsics or whatnot.
> Creating PIC
> code at all is not covered by the standard.
Again irrelevant. The standard does not specify anything about ABI,
and PIC is PURELY part of the ABI. It has absolutely nothing to do
with the language. A PIC-based compiler and a non-PIC-based compiler
are equally conformant, given all other things being equal.
> 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
No it does not make sense. Visibility and PIC are orthogonal and
visibility is not remotely needed for PIC. Even if such a feature as
visibility were warranted, it should be implemented with compiler
options and supplemental symbol list files or something like that, not
with language extensions polluting the source.
> 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.
s/by some standard//
Meeting the standards is a necessary evil, because it's the best
common ground we have for portability. That doesn't mean stuff is
automatically good just because it's in a standard.
> You don't seem to
> understand how most standardization happens.
Yes I do. This is one reason why it's evil. Once lots of
implementations add nasty bloat it starts moving towards being
standardized. The more people hold out against it and keep it
controversial, the better the chance of keeping it out of standards.
> 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.
Doubtful because there is no relevant standard. ISO C does not touch
such issues because it's made to be relevant to a very wide range of
systems, not just desktop/user-oriented stuff. It doesn't even have
the necessary definitions for visibility to make sense. POSIX is
similar in nature, and also doesn't get into the business of imposing
language extensions beyond the C language anyway. SUSv3 is the only
presently relevant standard that could ever possibly impose such a
thing (in the XSI extensions or another extension), but so far it also
doesn't mandate language extensions, and I suspect there will be
sufficiently many purists around to keep it as such.
Visibility is PURELY an optimization hack for ELF. It's not a feature
necessary for doing anything that's not doable without it. Thus it
More information about the ffmpeg-devel