rpath handling

[Toshio Kuratomi]

On Thu, Jun 24, 2010 at 09:18:30AM -0400, Colin Walters wrote:
> On Wed, Jun 23, 2010 at 10:04 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> >
> > What is being run at build time needing which rpath in order to function?
> 
> The GObject type system as currently designed defines some components
> (like properties and signals) in C code, and this has necessitated
> running a binary to extract that data.
> 
> I would *love* to be in a future where we can rely on the static
> introspection scanning and don't need to be running a binary, but
> we're not there yet.
> 
> > And is gtk-doc running something specially because this is glib2 or is it
> > running things every single build?  (Back in the day, it just extracted
> > things from source code comments, so I'm not sure what this new behaviour is
> > doing).
> 
> Nope, it's always created a binary.
> 
> [walters at pocket gobject-introspection (transformer)]$ grep Copyright
> /usr/bin/gtkdoc-scangobj
> # Copyright (C) 1998  Damon Chaplin
> [walters at pocket gobject-introspection (transformer)]
>
Interesting, maybe I jsut didn't need it for whatever I was doing back then
(It would have been around 1998 so I guess it must have been present).  But
this doesn't really answer the question of what's going wrong.  The
gtkdoc-scanobj program that's being run is compiled each time or it's the
one installed by gtk-doc?  What is rpath being embedded into?  The libraries
or a newly compile gtkdoc-scanobj or something else?  Does some program need
to be put into the rpm and installed onto the end user's systems with an
rpath set?  What is the rpath that we don't want stripped out?  Why is
setting LD_LIBRARY_PATH in the build environment not sufficient?

There's probably some overlap in there.  I don't understand the problem you're
encountering sufficiently yet to figure out why you're proposing this
specific solution instead of any number of different ones.

-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/7fdc091b/attachment.bin