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

[Trent Piepho]

xOn Sat, 12 May 2007, Rich Felker wrote:
> On Sun, May 13, 2007 at 01:02:12AM +0200, Michael Niedermayer wrote:
> > > x86-64's lack of support for textrels is entirely a limitation/bug of the tool
> > > chain.  It's not, it's a limitation of the architecture.
> >
> > and here you are wrong, it is purely a limitation of the toolchain
> > we could play a game so i can proof it to you, just give me some simple C
> > code and ill give you some theoretically 64bit relocateable x86-64 code
>
> Note that this claim inherently MUST be wrong, because normal non-PIC
> .o files work, either as static libs or just part of the main program.
> These contain relocations until they're linked. So there must be some
> way of handling it. Whether this way supports addressed beyond 4gig, I
> have no idea, but nonetheless it's done in practice and the same would
> work just as well at runtime as it does at linktime.

You already have the answer.  It doesn't support addresses beyond 4 gig.
When you create a non-DSO, like a normal executable, it must fit under 4GB.
It loads at a base address of zero, so 32-bit displacement fields are
enough to address any symbol resolved at link time, provided they all fit
into 4 GB.

As soon as you want to load an object above 4GB, text relocations won't work.
If want to require that addresses >4GB are never used, you'll need to
create whole new kernel with some new "amd-64/2" memory model that is
strictly 32-bit addressed.  I suspect there are MMU issues that make that
difficult, but I don't know.  It seems no one thinks text relocations are
worth it.

But it remains that x86-64 can't use text relocations unless you are
somehow able to entirely give up the 64-bit address space.

> > > Accessing a global variable using PIC code requires double indirection via the
> > > GOT.  Not true.  The extra indirection is for accessing a symbol from a
> > > different DSO.  PIC only requires the use of an extra register holding the
> > > base address in the address calculation.
> >
> > accessing a global variable using PIC by default does double indirection
> > most libs use that default
> > and with all the non portable tricks accesses to global vars of other DSOs
> > still need double indirection
>
> Indeed, he meant different compilation unit (.c/.o file), not
> different DSO. Unless you use evil visibility hacks...

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.

The ELF default is that non-static global variables may come from different
DSOs.  This is perhaps an unfortunate choice.  Windows does it the opposite
way.  It is not unsolvable as there are quite a few ways in which one can
change the default.