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@xxxxxxxxx> 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@pocket gobject-introspection (transformer)]$ grep Copyright > /usr/bin/gtkdoc-scangobj > # Copyright (C) 1998 Damon Chaplin > [walters@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
Attachment:
pgp1d2kArOzHn.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
