[PATCH] Apitrace replay: Fix "apitrace replay" regression when used with fips

[Lawrence Love]

On 11/29/2013 02:56 PM, Carl Worth wrote:
>
> Finally, I am interested in folding in the approach from glaze into fips
> directly. A couple of things have kept me back so far, (which might just
> be my own bugs as opposed to any fault in the actual approach). One is
> that the LD_LIBRARY_PATH-based approach fails when an application has
> rpath, (which, hopefully won't be a problem for much packaged or
> shipping software, but does often happen with software compiled on a
> developer's system).
>
>

I saw this in Wikipedia 
<http://en.wikipedia.org/wiki/Rpath#The_role_of_GNU_ld>; would that 
help? (didn't look into other platforms)


      The role of GNU ld[edit
      <http://en.wikipedia.org/w/index.php?title=Rpath&action=edit&section=3>]

The GNU Linker (GNU ld) implements a feature which it calls 
"new-dtags":^<http://en.wikipedia.org/wiki/Rpath#cite_note-2>

If the new-dtags feature is enabled in the linker (at run time 
using|--enable-new-dtags|), GNU|ld|, besides setting the|DT_RPATH| 
attribute, also sets the|DT_RUNPATH|attribute to the same string. At run 
time, if the dynamic linker finds a|DT_RUNPATH|attribute, it ignores the 
value of the|DT_RPATH|attribute, with the effect that|LD_LIBRARY_PATH|is 
checked next and the paths in the|DT_RUNPATH |attribute are only 
searched/after/it.

This means that in such configurations, the paths in|LD_LIBRARY_PATH|are 
searched before those given at link time 
using|-rpath|if|--enable-new-dtags|was active.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20131202/11b7eb10/attachment.html>