Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Thursday, 01 September 2005, at 14:39:22 (+0800), Didier Casse wrote: > This is provided from Ville Skytt=E4 author of the fedora-rpmdevtools--- > But the author of the check-rpath sript is Enrico Scholz > <[EMAIL PROTECTED]>. Maybe we should ask him > too. Enrico and I have some very fundamental differences of opinion when it comes to such matters, so I'll just leave it at that. :) > Mind you, the case of "standard library paths" in RPATH is the least > severe "error" detected by check-rpaths. What's more useful in it in > general are the checks for RPATHS that might cause security problems > (empty RPATHs, buildroot remainders etc). Yes, those are the real problems. The "standard library path" thing should be a warning, not an error, IMHO. > As far as I can tell, standard paths like /usr/lib in RPATH are > mainly of academic interest and the cases where they'd bite are very > rare in practice. I sure can't think of any, and the examples on that Debian page were very much on crack. > But if they don't add any value whatsoever on our platform (and can > at least theoretically be harmful), why not just get rid of them? If you can auto-fix them, I agree 100%. But considering a package "broken" because there's a 0.001% probability that Bubba down in Antarctica will encounter a problem is just silly IMHO. But I've already given the okay for the patch, so I'll let it go. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "But what better way to go out than in the cause of advancing scientific knowledge?" "Is this a multiple choice question? 'cause I have some ideas" -- Jim Ishida and Claudia Christian, Babylon Five --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Thu, 1 Sep 2005 02:10:26 -0400 Michael Jennings <[EMAIL PROTECTED]> babbled: > On Thursday, 01 September 2005, at 08:28:17 (+0900), > Carsten Haitzler wrote: > > > > well, as you can see, some distro's like to clamp down on RPATH's (for > > > whatever reasons/policies/boredom) > > > > > > so Eterm is going to be changed, it'd just be nice if we could do it with > > > a simple ./configure option rather than patching it ourselves ;) > > > -mike > > > > but what is the REASON for this rpath removal policy? i'm curious to know > > why! i'm wondering how it causes problems or breaks things or such... ? i'd > > really like to know! :) > > Exactly! Couldn't have said it better myself. :) indeed - i mean if it does cause problems in some obscure cases we don't know about - then you have a very good reason to have such a policy. some examples would be good. if you don't have good reasons i'd place the "policy" in serious doubt - i still dont see a problem in having an option to remove rpaths if spanky wants to add the options for us (thanks man!) - no work to be done then - saves distro's post-patching, but i'd still love to know why! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On 9/1/05, Michael Jennings <[EMAIL PROTECTED]> wrote: > On Thursday, 01 September 2005, at 08:28:17 (+0900), > Carsten Haitzler wrote: > > > > well, as you can see, some distro's like to clamp down on RPATH's (for > > > whatever reasons/policies/boredom) > > > > > > so Eterm is going to be changed, it'd just be nice if we could do it with > > > a > > > simple ./configure option rather than patching it ourselves ;) > > > -mike > > > > but what is the REASON for this rpath removal policy? i'm curious to know > > why! > > i'm wondering how it causes problems or breaks things or such... ? i'd > > really > > like to know! :) > > Exactly! Couldn't have said it better myself. > This is provided from Ville Skyttä author of the fedora-rpmdevtools--- But the author of the check-rpath sript is Enrico Scholz <[EMAIL PROTECTED]>. Maybe we should ask him too. -- >From Ville: Here's something: http://people.debian.org/~che/personal/rpath-considered-harmful http://wiki.debian.net/index.cgi?RpathIssue Mind you, the case of "standard library paths" in RPATH is the least severe "error" detected by check-rpaths. What's more useful in it in general are the checks for RPATHS that might cause security problems (empty RPATHs, buildroot remainders etc). As far as I can tell, standard paths like /usr/lib in RPATH are mainly of academic interest and the cases where they'd bite are very rare in practice. But if they don't add any value whatsoever on our platform (and can at least theoretically be harmful), why not just get rid of them? For more information, see the contents of the check-rpaths and check-rpaths-worker scripts, including the information about the scripts' author's email address; I'm sure Enrico would be happy to provide more insightful information if needed. -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wednesday, 31 August 2005, at 18:08:01 (-0400), Mike Frysinger wrote: > Index: configure.in > === > RCS file: /cvsroot/enlightenment/eterm/Eterm/configure.in,v > retrieving revision 1.93 > diff -u -p -r1.93 configure.in ... Looks fine to me. I still don't get it, but whatever. Commit it. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "No one can see their reflection in running water. It is only in still water that we can see." -- Taoist Proverb --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Thursday, 01 September 2005, at 08:28:17 (+0900), Carsten Haitzler wrote: > > well, as you can see, some distro's like to clamp down on RPATH's (for > > whatever reasons/policies/boredom) > > > > so Eterm is going to be changed, it'd just be nice if we could do it with a > > simple ./configure option rather than patching it ourselves ;) > > -mike > > but what is the REASON for this rpath removal policy? i'm curious to know > why! > i'm wondering how it causes problems or breaks things or such... ? i'd really > like to know! :) Exactly! Couldn't have said it better myself. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Have I told you today how much I love you?" "Yes, but you may continue to repeat it for as long as you like." -- President Sheridan and Delenn, "Babylon Five" --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wed, 31 Aug 2005 18:08:01 -0400 Mike Frysinger <[EMAIL PROTECTED]> babbled: > On Wednesday 31 August 2005 10:23 am, Michael Jennings wrote: > > On Wednesday, 31 August 2005, at 01:43:47 (-0400), > > > > Mike Frysinger wrote: > > > it makes a difference to us distro maintainers who wish to remove it > > > > To what end? What do you hope to accomplish? What does removing it > > gain you that makes it worth the effort (not to mention the added > > configure/Makefile cruft)? > > well, as you can see, some distro's like to clamp down on RPATH's (for > whatever reasons/policies/boredom) > > so Eterm is going to be changed, it'd just be nice if we could do it with a > simple ./configure option rather than patching it ourselves ;) > -mike but what is the REASON for this rpath removal policy? i'm curious to know why! i'm wondering how it causes problems or breaks things or such... ? i'd really like to know! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wednesday 31 August 2005 10:23 am, Michael Jennings wrote: > On Wednesday, 31 August 2005, at 01:43:47 (-0400), > > Mike Frysinger wrote: > > it makes a difference to us distro maintainers who wish to remove it > > To what end? What do you hope to accomplish? What does removing it > gain you that makes it worth the effort (not to mention the added > configure/Makefile cruft)? well, as you can see, some distro's like to clamp down on RPATH's (for whatever reasons/policies/boredom) so Eterm is going to be changed, it'd just be nice if we could do it with a simple ./configure option rather than patching it ourselves ;) -mike Index: configure.in === RCS file: /cvsroot/enlightenment/eterm/Eterm/configure.in,v retrieving revision 1.93 diff -u -p -r1.93 configure.in --- configure.in 14 Jun 2005 19:39:00 - 1.93 +++ configure.in 31 Aug 2005 22:07:29 - @@ -235,6 +235,24 @@ AC_SEARCH_LIBS(logout, util) AC_SEARCH_LIBS(getpwuid, sun) dnl# +dnl# Portable RPATH settings +dnl# +AC_MSG_CHECKING(how to define RPATH) +AC_ARG_ENABLE(default-rpaths, [ --disable-default-rpaths do not add default paths to RPATH], [ + if test "$enableval" == "no"; then + enable_default_rpaths=no + else + enable_default_rpaths=yes + fi], [enable_default_rpaths=yes]) +if test "$enable_default_rpaths" = "yes"; then +ETERM_RPATHS="\$(libdir):\$(pkglibdir)" +else +ETERM_RPATHS="\$(pkglibdir)" +fi +AC_SUBST(ETERM_RPATHS) +AC_MSG_RESULT($ETERM_RPATHS) + +dnl# dnl# Utility stuff dnl# dnl# Did they want debugging? Index: utils/Makefile.am === RCS file: /cvsroot/enlightenment/eterm/Eterm/utils/Makefile.am,v retrieving revision 1.8 diff -u -p -r1.8 Makefile.am --- utils/Makefile.am 15 Mar 2005 21:48:14 - 1.8 +++ utils/Makefile.am 31 Aug 2005 22:07:29 - @@ -4,7 +4,7 @@ bin_PROGRAMS = Esetroot Etbg Ettable bin_SCRIPTS = Etcolors Etsearch kEsetroot Etbg_update_list Esetroot_SOURCES = Esetroot.c -Esetroot_LDFLAGS = -rpath $(libdir):$(pkglibdir) +Esetroot_LDFLAGS = -rpath $(ETERM_RPATHS) Etbg_SOURCES = Etbg.c Ettable_SOURCES = Ettable.c Index: src/Makefile.am === RCS file: /cvsroot/enlightenment/eterm/Eterm/src/Makefile.am,v retrieving revision 1.30 diff -u -p -r1.30 Makefile.am --- src/Makefile.am 14 Jun 2005 19:39:01 - 1.30 +++ src/Makefile.am 31 Aug 2005 22:07:29 - @@ -36,7 +36,7 @@ endif Eterm_SOURCES = main.c Eterm_DEPENDENCIES = libEterm.la -Eterm_LDFLAGS = -rpath $(libdir):$(pkglibdir) +Eterm_LDFLAGS = -rpath $(ETERM_RPATHS) Eterm_LDADD = libEterm.la EXTRA_DIST = mmx_cmod.S sse2_cmod.c
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wednesday, 31 August 2005, at 01:43:47 (-0400), Mike Frysinger wrote: > it makes a difference to us distro maintainers who wish to remove it To what end? What do you hope to accomplish? What does removing it gain you that makes it worth the effort (not to mention the added configure/Makefile cruft)? Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Normal is in the eye of the beholder."-- Whoopi Goldberg --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wednesday 31 August 2005 01:36 am, Michael Jennings wrote: > On Wednesday, 31 August 2005, at 00:06:29 (-0400), > > Mike Frysinger wrote: > > so default the behavior to on, doesnt really matter to me so long as > > i can do `./configure --disable-default-rpaths` rather than patching > > it out > > What difference does it make? It's just not important, nor is it > worth the effort. it makes a difference to us distro maintainers who wish to remove it i'm not asking you to put in the effort, i'm just asking for your approval ... i'll make the required changes to the Eterm sources -mike --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wednesday, 31 August 2005, at 00:06:29 (-0400), Mike Frysinger wrote: > so default the behavior to on, doesnt really matter to me so long as > i can do `./configure --disable-default-rpaths` rather than patching > it out What difference does it make? It's just not important, nor is it worth the effort. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "The Road I have travelled on is paved with good intentions. It's littered with broken dreams that never quite came true." -- Restless Heart, "When She Cries" --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On 8/31/05, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Tuesday 30 August 2005 11:30 pm, Michael Jennings wrote: > > On Tuesday, 30 August 2005, at 23:19:41 (-0400), > > > > Mike Frysinger wrote: > > > or configure.in/Makefile.am could be updated to make this a buildtime > > > option and default to off for say linux hosts > > > > > > but considering your explanation in the previous e-mail, i dont think > > > you'll go for this ;) > > > > Just because it's a Linux host doesn't mean the builder will have > > root. The same principles work on Linux. > > so default the behavior to on, doesnt really matter to me so long as i can do > `./configure --disable-default-rpaths` rather than patching it out I guess I would be in favor of that too. :) -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Tuesday 30 August 2005 11:30 pm, Michael Jennings wrote: > On Tuesday, 30 August 2005, at 23:19:41 (-0400), > > Mike Frysinger wrote: > > or configure.in/Makefile.am could be updated to make this a buildtime > > option and default to off for say linux hosts > > > > but considering your explanation in the previous e-mail, i dont think > > you'll go for this ;) > > Just because it's a Linux host doesn't mean the builder will have > root. The same principles work on Linux. so default the behavior to on, doesnt really matter to me so long as i can do `./configure --disable-default-rpaths` rather than patching it out -mike --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Tuesday, 30 August 2005, at 23:19:41 (-0400), Mike Frysinger wrote: > or configure.in/Makefile.am could be updated to make this a buildtime option > and default to off for say linux hosts > > but considering your explanation in the previous e-mail, i dont think you'll > go for this ;) Just because it's a Linux host doesn't mean the builder will have root. The same principles work on Linux. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "I'm not talking about moving in, and I don't want to change your life. But there's a warm wind blowing, the stars are out, and I'd really love to see you tonight." -- England Dan and John Ford Coley --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Tuesday 30 August 2005 11:02 pm, Michael Jennings wrote: > On Tuesday, 30 August 2005, at 22:16:40 (-0400), > Mike Frysinger wrote: > > setting the rpath to the system paths is generally pointless and forces > > Eterm to load libraries from /usr/lib before looking at user-specified > > paths (from ld.so.conf or more importantly the LD_LIBRARY_PATH envvar) > > > > if you read the ELF spec, it dictates that the dynamic loader will search > > DT_RPATH paths (/usr/lib and /usr/lib/Eterm here) before checking > > LD_LIBRARY_PATH > > That is correct, and entirely meaningless. > > The reason it's done is so that LD_LIBRARY_PATH is not required on > platforms (like Solaris) without ld.so.conf and such. Sure, in your > particular case, $(libdir) and $(prefix)/lib and so forth may all be > the same and may all be system paths. That is NOT the case in > general, and adding the rpaths hurts NOTHING whatsoever. or configure.in/Makefile.am could be updated to make this a buildtime option and default to off for say linux hosts but considering your explanation in the previous e-mail, i dont think you'll go for this ;) -mike --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Tuesday, 30 August 2005, at 22:16:40 (-0400), Mike Frysinger wrote: > i wouldnt call it a bad idea ... running automated QA tests on ELF's is a > great idea Sure, but they're pointing out a problem where there is none. > i dont think anything is wrong with the script ... just taking a > guess here, but i think the behavior described is what is supposed > to happen with the check-rpaths script ... I'm sure it is. That doesn't mean it's not misguided. > setting the rpath to the system paths is generally pointless and forces Eterm > to load libraries from /usr/lib before looking at user-specified paths (from > ld.so.conf or more importantly the LD_LIBRARY_PATH envvar) > > if you read the ELF spec, it dictates that the dynamic loader will search > DT_RPATH paths (/usr/lib and /usr/lib/Eterm here) before checking > LD_LIBRARY_PATH That is correct, and entirely meaningless. The reason it's done is so that LD_LIBRARY_PATH is not required on platforms (like Solaris) without ld.so.conf and such. Sure, in your particular case, $(libdir) and $(prefix)/lib and so forth may all be the same and may all be system paths. That is NOT the case in general, and adding the rpaths hurts NOTHING whatsoever. If one wants to force one's own libraries before those specified in the executable's linking, one should be using LD_PRELOAD. > had i noticed this myself earlier, i would have patched Eterm in Gentoo to > stop forcing 'bogus' rpath's ;) They're not bogus. It's called "portability," though I know many people around here don't care about that sort of thing Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "But when two people are at one in their inmost hearts, they shatter even the strength of iron or of bronze." -- The I Ching --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Tuesday 30 August 2005 09:44 pm, Didier Casse wrote: > On 8/31/05, Michael Jennings <[EMAIL PROTECTED]> wrote: > > On Sunday, 28 August 2005, at 17:04:11 (+0800), > > > > Didier Casse wrote: > > > Hi all, > > > I get a little snag building rpms of the current cvs Eterm > > > on FC4. It keeps bugging me with the message: > > > > > > ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in > > > [/usr/lib:/ usr/lib/Eterm] > > > > > > See below: > > > > > > > > > [SNIP] > > > + /usr/lib/rpm/find-debuginfo.sh > > > /home/didier/rpmbuild/BUILD/Eterm-0.9.4 extracting debug info from > > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/lib/ > > > libEterm-0.9.4.so > > > extracting debug info from > > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Eterm > > > extracting debug info from > > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Ettable > > > extracting debug info from > > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Esetroot > > > extracting debug info from > > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Etbg > > > 0 blocks > > > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot > > > > > > This is not in rpm 4.4.1 or 4.4.2 as far as I can tell. Where did > > this script come from? It is a very bad idea and should be disabled. i wouldnt call it a bad idea ... running automated QA tests on ELF's is a great idea > Gulp :( > > This is why I use it! The FC3 version do not produce any errors on > Eterm while the FC4 version seems to scream at it. I guess as a way to > solve the problem I could probably disable it and use mzbuild. > > Or I might ask the authors Warren Togami et al. (Fedora US) what the > problem could be with the script at the moment. i dont think anything is wrong with the script ... just taking a guess here, but i think the behavior described is what is supposed to happen with the check-rpaths script ... setting the rpath to the system paths is generally pointless and forces Eterm to load libraries from /usr/lib before looking at user-specified paths (from ld.so.conf or more importantly the LD_LIBRARY_PATH envvar) if you read the ELF spec, it dictates that the dynamic loader will search DT_RPATH paths (/usr/lib and /usr/lib/Eterm here) before checking LD_LIBRARY_PATH had i noticed this myself earlier, i would have patched Eterm in Gentoo to stop forcing 'bogus' rpath's ;) -mike --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Wednesday, 31 August 2005, at 09:44:12 (+0800), Didier Casse wrote: > It's the fedora-rpmdevtools. It's suppose to have some nice scripts like: > > fedora-buildrpmtree Create RPM build tree within user's home directory > fedora-installdevkeys Install developer keys in alternate RPM keyring > fedora-kmodhelper Helper script for building kernel module RPMs > fedora-md5 Display the md5sum of all files in an RPM > fedora-newrpmspec Creates new .spec from template > fedora-pkgannfmtProduce output for fedora-package-announce > fedora-rmdevelrpms Find (and optionally remove) "development" RPMs > fedora-rpmchecksig Check package signatures using alternate RPM keyrin= > g > fedora-rpmvercmpRPM version comparison checker > fedora-unrpmExtract an RPM, "tar xvf" style > fedora-diffrpm Diff contents of two RPMs > fedora-wipebuildtreeErases all files within dirs created by buildrpmtre= > e Most of this stuff is either useless, trivial, or already included in Mezzanine in a much cleaner form. :-) (For what it's worth, the current RPM project leader has complimented Mezzanine numerous times and has expressed an interest in working together, so it's not just me tooting my own horn here.) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Was your bad playing today due to ignorance or apathy?" "I don't know, and I don't care." -- Frank Layden and Jeff Wilkins, Utah Jazz Coach and Forward, respectively --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On 8/31/05, Michael Jennings <[EMAIL PROTECTED]> wrote: > On Sunday, 28 August 2005, at 17:04:11 (+0800), > Didier Casse wrote: > > > Hi all, > > I get a little snag building rpms of the current cvs Eterm > > on FC4. It keeps bugging me with the message: > > > > ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in > > [/usr/lib:/ usr/lib/Eterm] > > > > See below: > > > > > > [SNIP] > > + /usr/lib/rpm/find-debuginfo.sh /home/didier/rpmbuild/BUILD/Eterm-0.9.4 > > extracting debug info from > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/lib/ > > libEterm-0.9.4.so > > extracting debug info from > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Eterm > > extracting debug info from > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Ettable > > extracting debug info from > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Esetroot > > extracting debug info from > > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Etbg > > 0 blocks > > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot > > This is not in rpm 4.4.1 or 4.4.2 as far as I can tell. Where did > this script come from? It is a very bad idea and should be disabled. > > Michael Gulp :( It's the fedora-rpmdevtools. It's suppose to have some nice scripts like: fedora-buildrpmtree Create RPM build tree within user's home directory fedora-installdevkeys Install developer keys in alternate RPM keyring fedora-kmodhelper Helper script for building kernel module RPMs fedora-md5 Display the md5sum of all files in an RPM fedora-newrpmspec Creates new .spec from template fedora-pkgannfmtProduce output for fedora-package-announce fedora-rmdevelrpms Find (and optionally remove) "development" RPMs fedora-rpmchecksig Check package signatures using alternate RPM keyring fedora-rpmvercmpRPM version comparison checker fedora-unrpmExtract an RPM, "tar xvf" style fedora-diffrpm Diff contents of two RPMs fedora-wipebuildtreeErases all files within dirs created by buildrpmtree This is why I use it! The FC3 version do not produce any errors on Eterm while the FC4 version seems to scream at it. I guess as a way to solve the problem I could probably disable it and use mzbuild. Or I might ask the authors Warren Togami et al. (Fedora US) what the problem could be with the script at the moment. -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe Didier F.B Casse PhD candidate, Singapore Synchrotron Light Source (SSLS) National University of Singapore. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4
On Sunday, 28 August 2005, at 17:04:11 (+0800), Didier Casse wrote: > Hi all, > I get a little snag building rpms of the current cvs Eterm > on FC4. It keeps bugging me with the message: > > ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in > [/usr/lib:/ usr/lib/Eterm] > > See below: > > > [SNIP] > + /usr/lib/rpm/find-debuginfo.sh /home/didier/rpmbuild/BUILD/Eterm-0.9.4 > extracting debug info from > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/lib/ > libEterm-0.9.4.so > extracting debug info from > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Eterm > extracting debug info from > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Ettable > extracting debug info from > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Esetroot > extracting debug info from > /var/tmp/Eterm-0.9.4-1.20050825cvs-root-root/usr/bin/ Etbg > 0 blocks > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot This is not in rpm 4.4.1 or 4.4.2 as far as I can tell. Where did this script come from? It is a very bad idea and should be disabled. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Men always want to please women, but these last 15 years, women have been hard to please. If you want to resist the feminist movement, the simple way to do it is to give them what they want, and they'll defeat themselves." -- Jack Nicholson, "Vanity Fair," April 1994 --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
