[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Rich Felker]

On Wed, Sep 20, 2006 at 08:34:30PM +0300, Uoti Urpala wrote:
> On Wed, 2006-09-20 at 09:46 -0400, Rich Felker wrote:
> > On Wed, Sep 20, 2006 at 08:47:40AM +0300, Uoti Urpala wrote:
> > > The C language spec isn't even meant to cover everything relevant to
> > > creating real programs.
> > 
> > The _language_ is, just not the standard library. You never need a
> > construct that is not valid C to write real programs. On the other
> 
> So you don't need to write code that is not standard C, you just include
> or link it from a library. At least if you can get someone else to write
> the library.

In any case you need to be able to compile it all with a C compiler.

> > hand, POSIX does cover everything relevant to creating real programs
> > and also (quite wisely) does not specify such nonsense as visibility
> > because it's a _language_ issue. Making it an OS issue is a misguided
> 
> So here you say visibility is a language issue...

Yes, it's part of a language which is not C. My point is that POSIX
defers to ISO C on _all_ language issues. It defines a larger library
and host system semantics but the language is entirely ISO C, not "ISO
C plus extended keywords foo and bar"...

> > 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
> 
> .... and here you say it's outside the scope of C. I'm not sure what kind
> of definitions you'd need to use for "language issue" and "scope of C"
> for these statements to make sense.

The scope of C is defining a simple language whose constructs make
sense on any reasonable machine, not just on giant multiprocess
unix/windows/etc. hosts. This is why stuff like TLS does not belong in
C as well. Naturally the same thing can be done with the library,
which POSIX already specifies.

> A compiler does need to be aware of dynamic linking and visibility (or
> specifically whether the symbol is in the same shared object) because it
> affects how the symbols must be accessed. It's possible to use just a
> single -fpic compiler switch instead of per-symbol information, but then
> the compiler must assume the most expensive way to access all external
> symbols. And this is not the fault of ELF, any shared object system
> which doesn't modify the code at linktime would share those issues.

Not entirely. The decision of whether to use a direct call or the PLT
can be deferred until link (ld command, not rtld) time in all cases.
ELF model forces it to be delayed until rtld time, unless you use
-Bsymbolic or visibility control, which is stupid. In any case,
special support from the compiler is not needed for calls. PIC and
non-PIC calls look identical as far as the compiler is concerned.

For global variables it does matter, however global variables are evil
enough already and _prohibitively_ evil when imported from a shared
library. Doing so results in copy-relocations, which in turn introduce
ABI issues which the programmer will likely not be aware of. The only
way to avoid this is building the application (not only the library,
the app too) with PIC, which is not something you can reasonably
expect.

Also keep in mind that if gcc weren't stupid, it COULD use GOTOFF
addressing for external variables defined in the same translation
unit. It only uses GOT addressing because of ELF stupidity.

Rich