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

Rich Felker dalias
Sun May 13 05:51:46 CEST 2007

On Sat, May 12, 2007 at 08:01:30PM -0700, Trent Piepho wrote:
> 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.

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.

Of course the more practical solution is to consider x86-64 an arch
where all code must reside in 32bit-addressible space and then just
use 32bit relocations. The idea of having more than 4gig of code is
utter nonsense anyway.

> 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...

> 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


More information about the ffmpeg-devel mailing list