rpath handling

Toshio Kuratomi a.badger at gmail.com
Fri Jun 25 00:57:49 UTC 2010

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.

-------------- 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 

More information about the devel mailing list