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