[FFmpeg-cvslog] r11202 - trunk/configure

[Michael Niedermayer]

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)

change the API so we dont have any global exported and non const variables


also i think (or hope at least) that not the whole application must now
be PIC but rather just the file(s) accessing global exported and non const
variables from lavc*

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20071212/6a51c3e7/attachment.pgp>