FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-25-2010, 03:34 PM
Colin Walters
 
Default rpath handling

On Fri, Jun 25, 2010 at 11:25 AM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>
> 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.

No, libtool is adding an rpath fine; see below:

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

No, it's not a libtool bug. Please reread my earlier messages, I'm
not sure how I can make this more clear. But I'll rewrite it anyways:

The old glib2.spec:

%build
%configure --disable-gtk-doc --enable-static --with-runtime-libdir=../../%{_lib}
# remove rpaths
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_f lag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_ DIE|g' libtool

Note that libtool is mangled *before* we run make. This works fine if
we don't need to run gtk-doc during the build (but if we do, as if
we're running from a git snapshot, then we get screwed).

If we strip the rpaths *after* we run make, then we're fine. No
rpaths in the final Fedora glib2 RPMS, but we can still run stuff
uninstalled.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-25-2010, 04:55 PM
Toshio Kuratomi
 
Default rpath handling

On Fri, Jun 25, 2010 at 11:34:34AM -0400, Colin Walters wrote:
> On Fri, Jun 25, 2010 at 11:25 AM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> >
> > 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.
>
> No, libtool is adding an rpath fine; see below:
>
> > 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.
>
> No, it's not a libtool bug. Please reread my earlier messages, I'm
> not sure how I can make this more clear. But I'll rewrite it anyways:
>
I understand everything that you're saying. You are not understanding what
I'm saying.

> The old glib2.spec:
>
> %build
> %configure --disable-gtk-doc --enable-static --with-runtime-libdir=../../%{_lib}
> # remove rpaths
> sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_f lag_spec=""|g' libtool
> sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_ DIE|g' libtool
>
> Note that libtool is mangled *before* we run make. This works fine if
> we don't need to run gtk-doc during the build (but if we do, as if
> we're running from a git snapshot, then we get screwed).
>
> If we strip the rpaths *after* we run make, then we're fine. No
> rpaths in the final Fedora glib2 RPMS, but we can still run stuff
> uninstalled.
>

The fact that you have to use those sed lines shows that there's something
wrong somewhere as we normally don't need them to produce rpath-free
binaries if we're using Fedora or Red Hat libtool. Since you have the
ability to commit upstream, please fix glib2's build scripts.

If you can't figure out how to do that, you can get me a link to your srpm
that shows the issue and I'll take a look. I've asked for that three times
now, though, so at this point it'll have to go on my todo list as I've got
other things to finish off today.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-25-2010, 05:42 PM
Colin Walters
 
Default rpath handling

On Fri, Jun 25, 2010 at 12:55 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>
> The fact that you have to use those sed lines shows that there's something
> wrong somewhere as we normally don't need them to produce rpath-free
> binaries if we're using Fedora or Red Hat libtool. *Since you have the
> ability to commit upstream, please fix glib2's build scripts.

What do you mean by "Fedora libtool"? Ohh...I see, we have a patch
which does something...that's not entirely clear to me at first
glance, and there's no comment, or upstream bug link.

As far as using that, note the glib2 tarballs are actually typically
created on an Ubuntu system. So...

> If you can't figure out how to do that, you can get me a link to your srpm
> that shows the issue and I'll take a look.

Sure: http://fedorapeople.org/~walters/glib2-2.24.1-1.4.20100625git7cdc592a.fc13.src.rpm
(but it really seems easier to me to just fedora-cvs glib2 and inspect it...)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-25-2010, 05:44 PM
Matthias Clasen
 
Default rpath handling

On Fri, 2010-06-25 at 13:42 -0400, Colin Walters wrote:

> As far as using that, note the glib2 tarballs are actually typically
> created on an Ubuntu system. So...
>

What makes you think so ?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 07:36 AM
Toshio Kuratomi
 
Default rpath handling

On Fri, Jun 25, 2010 at 01:42:43PM -0400, Colin Walters wrote:
> On Fri, Jun 25, 2010 at 12:55 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> >
> > The fact that you have to use those sed lines shows that there's something
> > wrong somewhere as we normally don't need them to produce rpath-free
> > binaries if we're using Fedora or Red Hat libtool. *Since you have the
> > ability to commit upstream, please fix glib2's build scripts.
>
> What do you mean by "Fedora libtool"? Ohh...I see, we have a patch
> which does something...that's not entirely clear to me at first
> glance, and there's no comment, or upstream bug link.
>
Yeah -- I'm not sure of the current status. There were rumors a Fedora
release or two ago that we finally got something merged upstream that no
longer necessitated our patch. Which, once announced to devel list, was
prompty succeeded by builds being generated with rpaths for standard library
paths. I don't know how that was finally resolved (could have been a bug in
our libtool packaging rather than us needing to restore a Fedora-specific
patch, for instance) you'll have to ask the libtool maintainers about that.

> As far as using that, note the glib2 tarballs are actually typically
> created on an Ubuntu system. So...
>
Uh... but your use case is checking out from the git repo, correct? So
actually, you're going to be generating the libtool related files on
a Fedora system....

> > If you can't figure out how to do that, you can get me a link to your srpm
> > that shows the issue and I'll take a look.
>
> Sure: http://fedorapeople.org/~walters/glib2-2.24.1-1.4.20100625git7cdc592a.fc13.src.rpm
> (but it really seems easier to me to just fedora-cvs glib2 and inspect it...)

Well, I asked that too and you didn't reply. I checked out the tree and
found that the packages there are using release tarballs, not snapshots. So
I don't know what you're thinking here.

I've just commented out your libtool hacks and rebuilt the packages:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2273737

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

I don't see any rpaths in there:

$ objdump -p glib2-devel-2.24.1-1.4.20100625git7cdc592a.fc13.1.x86_64/usr/bin/* 2>1 |grep -i rpath
$

Could you explain why you think you need to do something special to get rid
of rpaths?

I also noticed a few things that are fishy with the package:

$ rpm -qpl glib2-devel-2.24.1-1.4.20100625git7cdc592a.fc13.1.x86_64.rpm|grep bin/gio-querymodules
/usr/bin/gio-querymodules-32
$ rpm -qpl glib2-2.24.1-1.4.20100625git7cdc592a.fc13.1.x86_64.rpm|grep bin/gio-querymodules
/usr/bin/gio-querymodules-32

It looks like your spec file is failing in two places:

* "if $host" conditionals aren't doing what you expect. I haven't tested but
I'd hazard a guess that $host is empty.
* You're including gio-querymodules-* in both the main package and -devel.
You probably want a %exclude in the devel package for that.

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

Thread Tools




All times are GMT. The time now is 08:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org