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

[Rich Felker]

On Sat, May 12, 2007 at 11:10:16PM -0700, Trent Piepho wrote:
> > False. The compiler just needs to generate code that loads a 64bit
> > immediate and uses it as an address for every single memory access,
> > and appropriate relocation records for these. Yes this is rather
> > inefficient and ugly, but that's the only way to solve the "problem"
> > if the platform is so broken.
> 
> If you want to do that, you could just use rip relative addressing to load
> the 64-bit base address.  It's a smaller instruction and doesn't require a
> relocation.
> 
> Instead of:
>   movq $0x0102030405060708, %rdx  # constant must be changed by textrel
>   movl (%rdx), %eax
> 
> Do this:
>   leaq 0x01020304(%rip), %rdx     # link time constant, no textrel
>   movl (%rdx), %eax

Forget about ELF "textrel" terminology. The rip-relative address is
not known until the relocation is resolved by the linker. It might not
be within 4gig of %rip, and then the linker will fail.

Again this is all stupid because having more than 4gig of code is
utter nonsense (even more than 100 meg of code is utter nonsense).

> The only point of using 64-bit relocations would be if you want to allow a
> single object to be larger than 4GB.  Otherwise using rip relative
> addressing allows for a smaller and faster code sequence _and_ avoids the
> need for a text relocation.

The only way (in C) you know the symbol resides in the same "object"
is if it's static, and then no relocation is involved. Whenever a
symbol is external, the compiler has _no_ knowledge of the final
address it will resolve to. The only correct approaches are either a
sort of 'deferred compiling' or just assuming the maximal address size
for all relocations. This is much like other archs where 'short call'
opcodes exist, but the 'long call' version must be used for extern
functions.

> > > The ELF default is that non-static global variables may come from different
> > > DSOs.  This is perhaps an unfortunate choice.
> >
> > Unfortunate but absolutely necessary to correctly implement the C
> > language.
> 
> Strange you would say that.  a.out doesn't allow for shared libraries to do
> that

As I wrote before to Michael, the Linux a.out shared library model is
NOT viable. This has nothing to do with the a.out format; it's a
Linuxism built on top of it. BSD had perfectly working a.out shared
libs, and other designs are possible as well.

> and it's one of the reasons that a.out is faster than ELF.  Sounds
> like your saying that a.out shared libraries aren't a correct
> implementation of the C language.

For the Linux ones, yes, that's exactly what I'm saying.

Rich