Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   rpath handling (http://www.linux-archive.org/fedora-development/390113-rpath-handling.html)

Colin Walters 06-23-2010 11:58 PM

rpath handling
 
Hello internet,

So I lost yesterday and part of today to what I thought was a libtool
bug, but turned out to be an interaction with Fedora's current primary
recommendation for rpath handling:

http://fedoraproject.org/wiki/RPath_Packaging_Draft

The main recommendation is to use sed to reach into libtool's guts,
which normally works (well, until libtool changes, then we have a lot
of copy and paste to fix, but that's another story). However, glib2
uses a program called "gtk-doc" which requires actually running an
uninstalled binary to extract some data from it. This fails with the
Fedora rpath handling approach because the rpath is required at build
time.

Thus, I came up with this fragment of shell, which has a few advantages:

# make install here
(cd $RPM_BUILD_ROOT; find | while read f; do if file $f | grep -q ':
ELF .*executable,'; then chrpath --delete $f; fi; done)

0) It fixes the above problem I had
1) It doesn't precariously depend on libtool's internal variables
2) It handles rpaths generated by build systems other than libtool

However, after writing this, it occurs to me that RPM itself ships a
check-rpath tool; can we consider defaulting to replacing all rpaths
for standard paths? From the draft, I don't see any downsides to this
- we wouldn't be stripping rpaths for internal libraries, just stuff
in /etc/ld.so.conf*.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Toshio Kuratomi 06-24-2010 02:04 AM

rpath handling
 
On Wed, Jun 23, 2010 at 07:58:18PM -0400, Colin Walters wrote:
> Hello internet,
>
> So I lost yesterday and part of today to what I thought was a libtool
> bug, but turned out to be an interaction with Fedora's current primary
> recommendation for rpath handling:
>
> http://fedoraproject.org/wiki/RPath_Packaging_Draft
>
> The main recommendation is to use sed to reach into libtool's guts,
> which normally works (well, until libtool changes, then we have a lot
> of copy and paste to fix, but that's another story). However, glib2
> uses a program called "gtk-doc" which requires actually running an
> uninstalled binary to extract some data from it. This fails with the
> Fedora rpath handling approach because the rpath is required at build
> time.
>
What is being run at build time needing which rpath in order to function?
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).

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Matthias Clasen 06-24-2010 02:29 AM

rpath handling
 
On Wed, 2010-06-23 at 22:04 -0400, Toshio Kuratomi wrote:
> On Wed, Jun 23, 2010 at 07:58:18PM -0400, Colin Walters wrote:
> > Hello internet,
> >
> > So I lost yesterday and part of today to what I thought was a libtool
> > bug, but turned out to be an interaction with Fedora's current primary
> > recommendation for rpath handling:
> >
> > http://fedoraproject.org/wiki/RPath_Packaging_Draft
> >
> > The main recommendation is to use sed to reach into libtool's guts,
> > which normally works (well, until libtool changes, then we have a lot
> > of copy and paste to fix, but that's another story). However, glib2
> > uses a program called "gtk-doc" which requires actually running an
> > uninstalled binary to extract some data from it. This fails with the
> > Fedora rpath handling approach because the rpath is required at build
> > time.
> >
> What is being run at build time needing which rpath in order to function?
> 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).

Its not new. gtk-doc has always used introspection to extract
information about enums, signals, properties, etc from GObject
libraries. What is different here is that Colin is pushing for building
from git, which makes it necessary to generate the docs at rpm build
time. When building regular rpms from tarballs, we traditionally prefer
to package pre-generated docs that are included in the tarball, to avoid
multilib problems.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Colin Walters 06-24-2010 01:18 PM

rpath handling
 
On Wed, Jun 23, 2010 at 10:04 PM, Toshio Kuratomi <a.badger@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@pocket gobject-introspection (transformer)]$ grep Copyright
/usr/bin/gtkdoc-scangobj
# Copyright (C) 1998 Damon Chaplin
[walters@pocket gobject-introspection (transformer)]
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Bastien Nocera 06-24-2010 01:18 PM

rpath handling
 
On Wed, 2010-06-23 at 19:58 -0400, Colin Walters wrote:
> Hello internet,
>
> So I lost yesterday and part of today to what I thought was a libtool
> bug, but turned out to be an interaction with Fedora's current primary
> recommendation for rpath handling:
>
> http://fedoraproject.org/wiki/RPath_Packaging_Draft

I also had problems with the rpath disabling in libpeas, where it makes
the gobject-introspection files generation fail.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Toshio Kuratomi 06-24-2010 06:11 PM

rpath handling
 
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@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@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Colin Walters 06-24-2010 06:28 PM

rpath handling
 
On Thu, Jun 24, 2010 at 2:11 PM, Toshio Kuratomi <a.badger@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.

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Toshio Kuratomi 06-25-2010 12:57 AM

rpath handling
 
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@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Colin Walters 06-25-2010 12:43 PM

rpath handling
 
On Thu, Jun 24, 2010 at 8:57 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>
> 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?

What changed is simply that I'm using my script "fedpkg-vcs" to inject
a git snapshot into the spec file. Because the git tree does not
contain pre-built documentation (unlike tarballs) I must run gtk-doc.
So that's why it wasn't seen up until now.

> Ah -- that sounds better. *I'm still not sure why it's needed at all.
> though.

Why stripping the rpath is needed? Or why I'm trying to make this
change in the glib2 spec file? If the latter - it's simple, I'd like
to "upstream" as much of my work to automate building from git as
possible so I don't need to have forked specfiles just to create
testing RPMs.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Toshio Kuratomi 06-25-2010 03:25 PM

rpath handling
 
On Fri, Jun 25, 2010 at 08:43:35AM -0400, Colin Walters wrote:
> On Thu, Jun 24, 2010 at 8:57 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> >
> > 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?
>
> What changed is simply that I'm using my script "fedpkg-vcs" to inject
> a git snapshot into the spec file. Because the git tree does not
> contain pre-built documentation (unlike tarballs) I must run gtk-doc.
> So that's why it wasn't seen up until now.
>
> > Ah -- that sounds better. *I'm still not sure why it's needed at all.
> > though.
>
> Why stripping the rpath is needed? Or why I'm trying to make this
> change in the glib2 spec file? If the latter - it's simple, I'd like
> to "upstream" as much of my work to automate building from git as
> possible so I don't need to have forked specfiles just to create
> testing RPMs.
>
None of the above. Why libtool isn't handling this rpath (and the binaries
created during the build process) correctly when it does in other software.

So if you have the package somewhere I can help you debug the libtool issue
and see if we need to do this, if there's a new libtool bug, or if there's
an issue in the way gtk-doc-scanobj is being built in the package.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


All times are GMT. The time now is 04:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.