[Ffmpeg-devel] Re: [PATCH] Fix compilation when using --disable-opts
Sun Apr 1 13:41:56 CEST 2007
Michael Niedermayer <michaelni at gmx.at> writes:
> On Sun, Apr 01, 2007 at 01:03:46PM +0200, Michael Niedermayer wrote:
>> > at least cabac.h, line 388
>> > "movzbl "MANGLE(ff_h264_lps_range)"(%0, %%ebx, 2), %%esi\n\t"
>> > and line 395
>> > "movzbl "MANGLE(ff_h264_lps_range)"("ret", "range", 2), "range" \n\t"\
>> > No way to make ff_h264_lps_range RIP-relative as needed to allow
>> > for PIC at least on AMD64 it seems. At least that is my understanding of
>> > the issue so far.
>> i always thought the broken shared lib loading used on linux these days
>> can do relocations ...
Just why is this so broken anyway? I don't consider having the option
to be broken as long as I'm not forced to use it.
>> anyway there are 3 obvious ways this code can be generated (indpendant of
>> asm vs. c)
>> 1. use relocations (fast execution, slow loading,
>> wastes some possibly alot of memory)
>> 2. use extra instructions (slow execution and this is speedcritical code,
>> wastes memory but less)
>> 3. use a global unique address for each shared lib (fast and wastes no mem,
>> also avoids all the other PIC overhead ...)
How would you ensure uniqueness between independently built libs? I
know some systems, e.g. Solaris, keep map files in /usr/lib so the
linker can pick a free address range. The problem with this is of
course that it falls down if you install libs in other locations.
> just to clarify this, with
> global i of course meant global on one system not global for the world or
I figured that's what you meant, although with a 64-bit address space
even truly globally unique addresses would be theoretically possible.
In practice there would of course be the problem of coordination.
Besides, no current CPUs have a full 64-bit address space.
mans at mansr.com
More information about the ffmpeg-devel