rpath handling

[Toshio Kuratomi]

On Thu, Jun 24, 2010 at 02:28:11PM -0400, Colin Walters wrote:
> On Thu, Jun 24, 2010 at 2:11 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > The
> > gtkdoc-scanobj program that's being run is compiled each time
> 
> That program itself compiles a new binary.
> 
> >  What is rpath being embedded into?
> 
> The binary created above.  The rpath refers to the uninstalled shared libraries.
> 
> > Does some program need
> > to be put into the rpm and installed onto the end user's systems with an
> > rpath set?
> 
> No.
> 
> > What is the rpath that we don't want stripped out?
> 
> None in this case; we're fine to strip all rpaths - but only *after*
> the build process is complete.
> 
> >  Why is
> > setting LD_LIBRARY_PATH in the build environment not sufficient?
> 
> Because it's Linux-specific and thus brings us back to the whole
> problem libtool was supposed to solve.
> 
So... AFAIK, libtool does solve this which is why I'm wondering why you're
seeing this.  Is the package that's giving you problems checked into the
rawhide cvs right now?

> Again, what I'm actually proposing here is that Fedora's build system
> should by default strip all rpaths for standard paths, not that people
> copy and paste my different shell goo over and over.
> I'm just using my different shell goo until we can fix it globally.
>
Ah -- that sounds better.  I'm still not sure why it's needed at all.
though.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100624/6bf7a5b1/attachment-0001.bin