[FFmpeg-cvslog] r11202 - trunk/configure

Måns Rullgård mans
Wed Dec 12 10:33:07 CET 2007


Rich Felker <dalias at aerifal.cx> writes:

> On Tue, Dec 11, 2007 at 09:02:09PM +0100, mru wrote:
>> Author: mru
>> Date: Tue Dec 11 21:02:09 2007
>> New Revision: 11202
>> 
>> Log:
>> do not create copy relocations when linking to shared libs
>> 
>> 
>> Modified:
>>    trunk/configure
>> 
>> Modified: trunk/configure
>> ==============================================================================
>> --- trunk/configure	(original)
>> +++ trunk/configure	Tue Dec 11 21:02:09 2007
>> @@ -1737,6 +1737,7 @@ enabled extra_warnings && check_cflags -
>>  check_ldflags -Wl,--warn-common
>>  check_ldflags $LDLATEFLAGS
>>  check_ldflags -Wl,-Bsymbolic
>> +check_ldflags -Wl,-z,nocopyreloc
>
> IMO this is a bad commit message. It does not tell the reason why the
> change was made, which I'm actually very curious about. Did this fix
> the weird bug after -Bsymbolic was added, and if so, how/why? I assume
> it must be working around some strange binutils bug...

It could be considered a binutils bug, but I'm sure the binutils devs
would disagree.

The problem arises when a non-PIC main executable references global
data in a shared library.  If the compiler, as is typical on x86-64,
uses a 32-bit offset to access the data, a simple text relocation will
not work if the offset after dynamic linking would need more than 32
bits.  Instead a copy relocation is created, whereby the dynamic
linker copies the global symbol to a position within range of the
non-PIC reference, and patches up the shared lib GOT to reference this
instead of the original location in the lib, redirecting accesses from
the lib to the newly made copy.

With -Bsymbolic, intra-library accesses do not use the GOT, and the
executable and lib end up using different copies of the same symbol.
The -z nocopyreloc flag tells the linker not to create such copy
relocations, but rather a normal text relocation.  As we all know,
text relocations on x86-64 don't work very well (hard to fit a 64-bit
offset in a 32-bit space), so we must build the main executable as PIC
as well.  If we do this, the main GOT is pointed at the library symbol
(instead of the opposite), and everything works as intended.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-cvslog mailing list