[FFmpeg-cvslog] r11202 - trunk/configure

[Måns Rullgård]

Michael Niedermayer wrote:
> On Wed, Dec 12, 2007 at 10:58:56AM -0000, M?ns Rullg?rd wrote:
>>
>> Michael Niedermayer wrote:
>> > On Wed, Dec 12, 2007 at 09:33:07AM +0000, M?ns Rullg?rd wrote:
>> >> 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.
>> >
>> > yes, alternative solutions would be
>> >
>> > somehow force accesses to the 5 global exported and non const variables
>> > to go through the GOT (i think this could be achived with linker scripts)
>>
>> No, the type of access is determined by the compiler.
>
> you missunderstood me i didnt mean the app but the lib, if the lib woul
> access these 5 variables so that they are overrideable then there wouldnt
> be a problem with copy relocations
> a -Bsymbolic NOT first_avcodec, ... is what i meant and i think that can be
> achived with linker scripts

I see.  Yes, that's probably possible, though I'd rather not spend time
figuring out how to do it if we can get rid of these exports more easily.

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