7:04 a.m.
I've noticed that there are still many binaries in /usr/bin that have
RPATH hardcoded in them.
On a x86_64 full installation there are 470 binaries with /usr/lib64
in RPATH. That looks like a lot of work to have this fixed and
maintained. Maybe a chrpath script could be used in the build process,
and remove automatically the obvious cases like /usr/lib64,
/usr/local/lib and @RPATH@ ?
470 /usr/lib64
47 /usr/lib64/lam
39 //usr/local/lib
20 /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE
13 /usr/lib64/mysql
12 /usr/lib64/htdig:/usr/lib64/htdig_db
7 @RPATH@
7 /usr/lib64/openmpi
7 /usr/lib64/kde3
5 /usr/lib64:/usr/lib
4 /usr/lib64:/usr/lib64
4 /usr/lib64/fedora-ds
3 /usr/lib64/firefox-2.0.0.2
2 /usr/lib64/qt-3.3/lib:/usr/lib64:/usr/lib/kde3
2 /usr/lib64/evolution/2.10
1 /usr/lib64:/usr/lib64/qt-3.3/lib
1 /usr/lib64:/usr/lib64/firefox-2.0.0.2
1 /usr/lib64:/usr/lib/gcj-4.1.2
1 /usr/lib64:/lib64
1 /usr/lib64/xfce4/modules
1 /usr/lib64/quagga
1 /usr/lib64/qt-3.3/lib:/usr/lib64/kde3
1 /usr/lib64/octave-2.9.9
1 /usr/lib64/kazehakase:/usr/lib64/firefox-2.0.0.2
1 /usr/lib64/gthumb
1 /usr/lib64/graphviz
1 /usr/lib64/gnucash
1 /usr/lib64/gnome-commander
1 /usr/lib64/ecl
1 /usr/lib64/dia
1 /usr/lib64/brltty
--
Miroslav Lichvar
7:43 a.m.
Hi.
On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote:
On a x86_64 full installation there are 470 binaries with /usr/lib64
in RPATH. That looks like a lot of work to have this fixed and
maintained. Maybe a chrpath script could be used in the build process,
and remove automatically the obvious cases like /usr/lib64,
/usr/local/lib and @RPATH@ ?
The right way would be to file bugs against the packages, I think.
8:14 a.m.
On 09.03.2007 14:43, Ralf Ertzinger wrote:
On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote:
> On a x86_64 full installation there are 470 binaries with /usr/lib64
> in RPATH. That looks like a lot of work to have this fixed and
> maintained. Maybe a chrpath script could be used in the build process,
> and remove automatically the obvious cases like /usr/lib64,
> /usr/local/lib and @RPATH@ ?
The right way would be to file bugs against the packages, I think.
The right way IMHO would be to enable the rpath checks on the buildsys,
so the build fails if rpath show up that are not whitelisted in the spec
file. Then way people notice the rpath and in most cases fix them; new
rpath further get noticed immediately, and we all save time as we don#t
have to file bugs :-) .
The checks are *iirc* enabled for the Extras builders. We should make
sure they get enabled for the new Fedora builders, too.
CU
thl
8:18 a.m.
Thorsten Leemhuis wrote:
On 09.03.2007 14:43, Ralf Ertzinger wrote:
> On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote:
>
>> On a x86_64 full installation there are 470 binaries with /usr/lib64
>> in RPATH. That looks like a lot of work to have this fixed and
>> maintained. Maybe a chrpath script could be used in the build process,
>> and remove automatically the obvious cases like /usr/lib64,
>> /usr/local/lib and @RPATH@ ?
> The right way would be to file bugs against the packages, I think.
The right way IMHO would be to enable the rpath checks on the buildsys,
so the build fails if rpath show up that are not whitelisted in the spec
file. Then way people notice the rpath and in most cases fix them; new
rpath further get noticed immediately, and we all save time as we don#t
have to file bugs :-) .
The checks are *iirc* enabled for the Extras builders. We should make
sure they get enabled for the new Fedora builders, too.
rpmlint catches this, I'm sitll in favor of running rpmlint after a build,
check the output against a whitelist of allowed output and if there is any
output not in the whitelist, fail the build. We would need to integrate the
same use of rpmlint in make <arch> from makefile.common then (or maybe first).
Regards,
Hans
8:21 a.m.
Hi.
On Fri, 09 Mar 2007 15:18:36 +0100, Hans de Goede wrote:
rpmlint catches this, I'm sitll in favor of running rpmlint after
a
build, check the output against a whitelist of allowed output and if
there is any output not in the whitelist, fail the build. We would
need to integrate the same use of rpmlint in make <arch> from
makefile.common then (or maybe first).
Livna does this already. Fine with me.
10:06 a.m.
Hans de Goede schrieb:
Thorsten Leemhuis wrote:
> On 09.03.2007 14:43, Ralf Ertzinger wrote:
>> On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote:
>>> On a x86_64 full installation there are 470 binaries with /usr/lib64
>>> in RPATH. That looks like a lot of work to have this fixed and
>>> maintained. Maybe a chrpath script could be used in the build process,
>>> and remove automatically the obvious cases like /usr/lib64,
>>> /usr/local/lib and @RPATH@ ?
>> The right way would be to file bugs against the packages, I think.
> The right way IMHO would be to enable the rpath checks on the buildsys,
> so the build fails if rpath show up that are not whitelisted in the spec
> file. Then way people notice the rpath and in most cases fix them; new
> rpath further get noticed immediately, and we all save time as we don#t
> have to file bugs :-) .
> The checks are *iirc* enabled for the Extras builders. We should make
> sure they get enabled for the new Fedora builders, too.
rpmlint catches this, I'm sitll in favor of running rpmlint after a build,
check the output against a whitelist of allowed output and if there is any
output not in the whitelist, fail the build. We would need to integrate the
same use of rpmlint in make <arch> from makefile.common then (or maybe first).
Sounds fine, too.
Cu
thl
11:01 a.m.
On 09/03/07, Hans de Goede <j.w.r.degoede(a)hhs.nl> wrote:
rpmlint catches this, I'm sitll in favor of running rpmlint after
a build,
check the output against a whitelist of allowed output and if there is any
output not in the whitelist, fail the build. We would need to integrate the
same use of rpmlint in make <arch> from makefile.common then (or maybe first).
Fantastic proposal. An added benefit would be that would be one step
closer to having part of the new package review process automated. If
there was a build machine where new package SRPMS could be pushed to
(perhaps even via a web interface) which would then try to build the
package inside mock, run rpmlint on resulting packages, and make
avilable all logs and output (also perhaps via a web page), then
package review pace would greatly increase, I suspect.
3:05 p.m.
Jonathan Underwood wrote:
On 09/03/07, Hans de Goede <j.w.r.degoede(a)hhs.nl> wrote:
> rpmlint catches this, I'm sitll in favor of running rpmlint after a
> build,
> check the output against a whitelist of allowed output and if there is
> any
> output not in the whitelist, fail the build. We would need to
> integrate the
> same use of rpmlint in make <arch> from makefile.common then (or maybe
> first).
Fantastic proposal. An added benefit would be that would be one step
closer to having part of the new package review process automated. If
there was a build machine where new package SRPMS could be pushed to
(perhaps even via a web interface) which would then try to build the
package inside mock, run rpmlint on resulting packages, and make
avilable all logs and output (also perhaps via a web page), then
package review pace would greatly increase, I suspect.
Okay,
I've taken a quick look at hacking this into Makefile.common, but I
think I'm not the right person todo this (I'm a C-programmer not a
script language one). Someone (Ville?) once wrote something about some
special way to feed a whitelist to rpmlint. Can anyone reproduce that
crucial piece of info?
Regards,
Hans
9:28 p.m.
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
rpmlint catches this, I'm sitll in favor of running rpmlint after
a build,
check the output against a whitelist of allowed output and if there is any
output not in the whitelist, fail the build. We would need to integrate the
same use of rpmlint in make <arch> from makefile.common then (or maybe
first).
Do we really want to hold up builds on the rpmlint maintainer fixing
things in rpmlint?
Bill
10:01 p.m.
On Fri, 2007-03-09 at 22:28 -0500, Bill Nottingham wrote:
Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
> rpmlint catches this, I'm sitll in favor of running rpmlint after a build,
> check the output against a whitelist of allowed output and if there is any
> output not in the whitelist, fail the build. We would need to integrate the
> same use of rpmlint in make <arch> from makefile.common then (or maybe
> first).
Do we really want to hold up builds on the rpmlint maintainer fixing
things in rpmlint?
If this is the same thought as past discussions, the whitelist is per
package. I make a build. The rpms are run through rpmlint. The issues
reported are compared against the previous build's rpmlint. If there
are problems not previously whitelisted, the rpm is not pushed to the
repo until the maintainer somehow adds the warnings to the whitelist or
updates the spec so it no longer causes the error. (Maybe it's filling
in a reason and submitting it to the packageDB. Maybe it's a specially
formatted comment in the spec file. I don't know how people would want
to implement the feature.)
So there's no waiting on the rpmlint maintainer. This could also be
interesting as it would let the rpmlint maintainer/author see which of
the rpmlint tests are causing the most false positives.
-Toshio
2:45 a.m.
Toshio Kuratomi wrote:
On Fri, 2007-03-09 at 22:28 -0500, Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>> rpmlint catches this, I'm sitll in favor of running rpmlint after a build,
>> check the output against a whitelist of allowed output and if there is any
>> output not in the whitelist, fail the build. We would need to integrate the
>> same use of rpmlint in make <arch> from makefile.common then (or maybe
>> first).
> Do we really want to hold up builds on the rpmlint maintainer fixing
> things in rpmlint?
>
If this is the same thought as past discussions, the whitelist is per
package. I make a build. The rpms are run through rpmlint. The issues
reported are compared against the previous build's rpmlint. If there
are problems not previously whitelisted, the rpm is not pushed to the
repo until the maintainer somehow adds the warnings to the whitelist or
updates the spec so it no longer causes the error. (Maybe it's filling
in a reason and submitting it to the packageDB. Maybe it's a specially
formatted comment in the spec file. I don't know how people would want
to implement the feature.)
My idea was to have a special file in CVS, which also gets tagged per
release just like the sources file.
Also notice that make <arch> should be patched first todo the same
thing, so that when a maintainer does a testbuild rpmlint is already run
and thus there are no surprises when rpmlint gets run on the buildsys.
I've been thinking about this for quite a while now actually as I very
regulary encounter packages with packaging errors which are caught by
rpmlint. And sometimes upstream causes packaging regressions like
introducing rpath in a new release. Automated QA is simply good, as long
as it doesn't get in the way and the whitelist makes sure it doesn't.
The whitelist should probably handle wildcards or regex, so maintainers
who really don't want this can simply put .* in the whitelist.
Regards,
Hans
6:02 a.m.
On Fri, 2007-03-09 at 20:01 -0800, Toshio Kuratomi wrote:
If this is the same thought as past discussions, the whitelist is
per
package. I make a build. The rpms are run through rpmlint. The issues
reported are compared against the previous build's rpmlint. If there
are problems not previously whitelisted, the rpm is not pushed to the
repo until the maintainer somehow adds the warnings to the whitelist or
updates the spec so it no longer causes the error. (Maybe it's filling
in a reason and submitting it to the packageDB. Maybe it's a specially
formatted comment in the spec file. I don't know how people would want
to implement the feature.)
I thought there's already a whitelist. There's (W)arnings and (E)rrors.
Just like a C compiler.
11:42 a.m.
Callum Lerwick (seg(a)haxxed.com) said:
I thought there's already a whitelist. There's (W)arnings and
(E)rrors.
Just like a C compiler.
You need per-package whitelists; i.e., it's OK for this package to
have this directory as 2775, this binary as 4755, etc. Trying to
maintain those all in rpmlint itself is doomed to fail.
Bill
10:58 a.m.
Miroslav Lichvar wrote:
I've noticed that there are still many binaries in /usr/bin that
have
RPATH hardcoded in them.
3 /usr/lib64/firefox-2.0.0.2
Some of them are intentional, such as the above. It's either rpath or
munging LD_LIBRARY_PATH at startup if you want a working firefox.
12:04 p.m.
On Fri, Mar 09, 2007 at 11:58:57AM -0500, Christopher Aillon wrote:
Miroslav Lichvar wrote:
>I've noticed that there are still many binaries in /usr/bin that have
>RPATH hardcoded in them.
> 3 /usr/lib64/firefox-2.0.0.2
Some of them are intentional, such as the above. It's either rpath or
munging LD_LIBRARY_PATH at startup if you want a working firefox.
BTW, the current packaging guidelines don't permit rpath at all and
suggest to put a config in /etc/ld.so.conf.d/, but that doesn't look
right in this case. I guess rpath for plugins/modules should be
allowed.
--
Miroslav Lichvar
3:13 p.m.
Christopher Aillon wrote:
> 3 /usr/lib64/firefox-2.0.0.2
Some of them are intentional, such as the above. It's either rpath or
munging LD_LIBRARY_PATH at startup if you want a working firefox.
RPATH is perfectly fine for these purposes.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
3:17 p.m.
Ulrich Drepper wrote:
Christopher Aillon wrote:
>> 3 /usr/lib64/firefox-2.0.0.2
> Some of them are intentional, such as the above. It's either rpath or
> munging LD_LIBRARY_PATH at startup if you want a working firefox.
RPATH is perfectly fine for these purposes.
[Dang it! why did it send the mail already?]
I meant to add:
If you want a relocatable package you can use $ORIGIN though. So, if
the binary is in /usr/bin (e.g., devhelp), you make the RPATH
$ORIGIN/../lib64/firefix-2.0.0.2
Then the package is relocatable (at least wrt to this binary).
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
4:46 a.m.
Ulrich Drepper <drepper(a)redhat.com> writes:
If you want a relocatable package you can use $ORIGIN though. So,
if
the binary is in /usr/bin (e.g., devhelp), you make the RPATH
$ORIGIN/../lib64/firefix-2.0.0.2
Back references (/..) should be avoided there because they will break
when binary is in a symlinked path. E.g. with
| /usr/bin -> /vol1/usr/bin
| /usr/lib64 -> /vol2/usr/lib64
the RPATH above would be resolved to /vol1/usr/lib64/...
Enrico
8:20 a.m.
Alexander Boström <abo(a)kth.se> writes:
> | /usr/bin -> /vol1/usr/bin
> | /usr/lib64 -> /vol2/usr/lib64
>
> the RPATH above would be resolved to /vol1/usr/lib64/...
Perhaps a bind mount would be better in situations like that?
Perhaps; but there is nothing which forbids the symlink layout. In
practice, I saw this with '/afs/.../bin -> ...' links; bind mounts
might be more complicated in such a setup.
Enrico
11:35 a.m.
Enrico Scholz wrote:
Back references (/..) should be avoided there because they will
break
when binary is in a symlinked path. E.g. with
| /usr/bin -> /vol1/usr/bin
| /usr/lib64 -> /vol2/usr/lib64
the RPATH above would be resolved to /vol1/usr/lib64/...
If you create such situations it's your own fault. $ORIGIN is meant to
be used with back references so stop spreading nonsense like this.
There are certain things, like keeping bin and lib{,64}, which not only
make sense but really are the only solution which makes sense.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
12:18 p.m.
Ulrich Drepper <drepper(a)redhat.com> writes:
> Back references (/..) should be avoided there because they will
break
> when binary is in a symlinked path. E.g. with
>
> | /usr/bin -> /vol1/usr/bin
> | /usr/lib64 -> /vol2/usr/lib64
>
> the RPATH above would be resolved to /vol1/usr/lib64/...
If you create such situations it's your own fault.
No; then the package is just broken because binaries can not find
required libraries.
$ORIGIN is meant to be used with back references
I do not think so; more common case is plain $ORIGIN or $ORIGIN/lib, and
there it makes sense. Nobody can guarantee where /.. really points to.
Enrico
6:26 p.m.
Enrico Scholz wrote:
> $ORIGIN is meant to be used with back references
I do not think so
What are you talking about? You must have implemented all this stuff
and know about it, right? Wait... it was I who did that.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
5:50 a.m.
Ulrich Drepper <drepper(a)redhat.com> writes:
>> $ORIGIN is meant to be used with back references
>
> I do not think so
What are you talking about? You must have implemented all this stuff
and know about it, right?
Sorry, when $ORIGIN was really designed to allow things like '$ORIGIN/..',
then the design of $ORIGIN is flawed.
Enrico
10:14 p.m.
Enrico Scholz wrote:
Sorry, when $ORIGIN was really designed to allow things like
'$ORIGIN/..',
then the design of $ORIGIN is flawed.
Nonsense. The whole assumption that every single moronic file system
setup must be supported is wrong. Not everything that is technically
possible is worth it. A ground rule must be that /usr/bin and
/usr/lib{,64} mustn't be symlinks.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
2:38 a.m.
On Wed, Mar 14, 2007 at 08:14:20PM -0700, Ulrich Drepper wrote:
Enrico Scholz wrote:
> Sorry, when $ORIGIN was really designed to allow things like '$ORIGIN/..',
> then the design of $ORIGIN is flawed.
Nonsense. The whole assumption that every single moronic file system
setup must be supported is wrong. Not everything that is technically
possible is worth it. A ground rule must be that /usr/bin and
/usr/lib{,64} mustn't be symlinks.
Well, they actually can, but they either need to point to sibling
directories (say /usr/bin -> /opt/foo/bar/bin, /usr/lib -> /opt/foo/bar/lib,
/usr/lib64 -> /opt/foo/bar/lib64) or if for whatever reason they are not,
then you need symlinks in both locations (say /usr/bin -> /opt/foo/bar/bin,
/usr/lib -> /opt/bar/baz/lib, then you'd need also /opt/foo/bar/lib ->
../../bar/baz/lib and /opt/bar/baz/bin -> ../../foo/bar/bin).
This is not just for the sake of $ORIGIN/.., e.g. gcc does a similar search
for libraries and other relocatable packages do so as well.
Jakub
6:14 p.m.
On Fri, 2007-03-09 at 13:13 -0800, Ulrich Drepper wrote:
Christopher Aillon wrote:
>> 3 /usr/lib64/firefox-2.0.0.2
>
> Some of them are intentional, such as the above. It's either rpath or
> munging LD_LIBRARY_PATH at startup if you want a working firefox.
RPATH is perfectly fine for these purposes.
Do we have a preference against wrapper scripts for munging
LD_LIBRARY_PATH (I think we should)?
The reason I ask is that I've been looking at the Fedora DS situation
(now a package in extras), where every binary is wrapped in a shell
script to munge the LD_LIBRARY_PATH, which just seems wrong to me.
Likewise, where should a package place 'internal only' libraries, such
as libslapd for Fedora DS, and some similar libraries in an eventual
Samba4 package (to avoid bloat by static linking shared internal
functionality)?
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
4:56 a.m.
sön 2007-03-11 klockan 11:14 +1100 skrev Andrew Bartlett:
The reason I ask is that I've been looking at the Fedora DS
situation
(now a package in extras), where every binary is wrapped in a shell
script to munge the LD_LIBRARY_PATH, which just seems wrong to me.
Yeah, it would be better to use RPATH.
If a process needs LD_LIBRARY_PATH set, but spawns other processes that
do not need it, it's asking for trouble. (For example, a web browser
that starts a PDF reader.)
/abo
6245
days inactive
6251
days old
28 comments
14 participants
participants (14)
-
Alexander Boström -
Andrew Bartlett -
Bill Nottingham -
Callum Lerwick -
Christopher Aillon -
Enrico Scholz -
Hans de Goede -
Jakub Jelinek -
Jonathan Underwood -
Miroslav Lichvar -
Ralf Ertzinger -
Thorsten Leemhuis -
Toshio Kuratomi -
Ulrich Drepper