From: SourceForge.net <no...@so...> - 2003-09-24 19:12:16
|
Bugs item #811978, was opened at 2003-09-24 21:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Herbert (marchash) Assigned to: Nobody/Anonymous (nobody) Summary: configure expands exec_prefix (stow issue) Initial Comment: Extract from configure shipped with 0.6.1: # Installation directory options. # These are left unexpanded so users can "make install exec_prefix=/foo" # and all the variables that are supposed to be based on exec_prefix # by default will actually change. # Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' ---- This is theory. Unfortunately in practice the current "config.h fixups" in configure expand $exec_prefix and spoil this. The attached patch (successfully tested with 0.6.1) enables the "stowing" of oprofile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 |
From: SourceForge.net <no...@so...> - 2003-09-24 20:15:37
|
Bugs item #811978, was opened at 2003-09-24 21:11 Message generated for change (Comment added) made by phil_e You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Herbert (marchash) Assigned to: Nobody/Anonymous (nobody) Summary: configure expands exec_prefix (stow issue) Initial Comment: Extract from configure shipped with 0.6.1: # Installation directory options. # These are left unexpanded so users can "make install exec_prefix=/foo" # and all the variables that are supposed to be based on exec_prefix # by default will actually change. # Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' ---- This is theory. Unfortunately in practice the current "config.h fixups" in configure expand $exec_prefix and spoil this. The attached patch (successfully tested with 0.6.1) enables the "stowing" of oprofile. ---------------------------------------------------------------------- >Comment By: Philippe Elie (phil_e) Date: 2003-09-24 22:15 Message: Logged In: YES user_id=318973 it's not sufficient afaics, if I remove previously installed version, apply you patch autogen.sh && configure && make && make install exec_prefix=/foo then oprof_start can't find opcontrol to start the profiler because we use OP_BINDIR in oprof_start. opcontrol contains also a hard-coded PATH= but it shouldn't matter (except it's probably a problem to use hard code path). I've some doubt make install prefix= will works too for some related problem. John, do we want to fix this ? regards, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 |
From: SourceForge.net <no...@so...> - 2003-09-25 12:48:58
|
Bugs item #811978, was opened at 2003-09-24 19:11 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 Category: None Group: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: Marc Herbert (marchash) Assigned to: Nobody/Anonymous (nobody) Summary: configure expands exec_prefix (stow issue) Initial Comment: Extract from configure shipped with 0.6.1: # Installation directory options. # These are left unexpanded so users can "make install exec_prefix=/foo" # and all the variables that are supposed to be based on exec_prefix # by default will actually change. # Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' ---- This is theory. Unfortunately in practice the current "config.h fixups" in configure expand $exec_prefix and spoil this. The attached patch (successfully tested with 0.6.1) enables the "stowing" of oprofile. ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2003-09-25 12:48 Message: Logged In: YES user_id=53034 The hardcoding of our base path is irritating and somewhat ugly, but I don't see a better solution at this point in time. I don't see the point in this patch until the oprofile binaries are properly relocatable. So I'm going to close this as LATER. Marc, if you can think of a nice solution to the oprof_start problem, we'd like to hear it. Note that some people are using oprof_start via sudo, so we can't simply search $PATH for the programs that oprof_start calls out to. ---------------------------------------------------------------------- Comment By: Philippe Elie (phil_e) Date: 2003-09-24 20:15 Message: Logged In: YES user_id=318973 it's not sufficient afaics, if I remove previously installed version, apply you patch autogen.sh && configure && make && make install exec_prefix=/foo then oprof_start can't find opcontrol to start the profiler because we use OP_BINDIR in oprof_start. opcontrol contains also a hard-coded PATH= but it shouldn't matter (except it's probably a problem to use hard code path). I've some doubt make install prefix= will works too for some related problem. John, do we want to fix this ? regards, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 |
From: SourceForge.net <no...@so...> - 2003-09-25 15:20:35
|
Bugs item #811978, was opened at 2003-09-24 21:11 Message generated for change (Comment added) made by marchash You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 Category: None Group: None >Status: Open Resolution: Later Priority: 5 Submitted By: Marc Herbert (marchash) Assigned to: Nobody/Anonymous (nobody) Summary: configure expands exec_prefix (stow issue) Initial Comment: Extract from configure shipped with 0.6.1: # Installation directory options. # These are left unexpanded so users can "make install exec_prefix=/foo" # and all the variables that are supposed to be based on exec_prefix # by default will actually change. # Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' ---- This is theory. Unfortunately in practice the current "config.h fixups" in configure expand $exec_prefix and spoil this. The attached patch (successfully tested with 0.6.1) enables the "stowing" of oprofile. ---------------------------------------------------------------------- >Comment By: Marc Herbert (marchash) Date: 2003-09-25 17:20 Message: Logged In: YES user_id=447685 The problem is that... you did not fully read my report :-) My patch does NOT aim at making oprofile binaries really relocatable, because the tool "stow" is enough to enable relocation of un-relocatable binaries, thanks to automated creation of symbolic links. Sorry, this patch is not the great relocation fix you were expecting, but still, it provides compatibility with the great, simple and widespread "stow" primitive package management tool. Have a look at stow here: <http://www.gnu.org/software/stow/manual.html> Stow can perfectly cope with the hardcoding of paths in binaries, as long as the _Makefiles_ stay clean. Thus my small patch. I suggest your give stow a try, it's as simple as: make install prefix=/usr/local/stow/oprofile-0.6.1-b4 cd /usr/local/stow/ stow --delete oprofile-0.6.1-b3 # disable b3 version stow oprofile-0.6.1-b4 # enable b4 version The commands above work only... with my patch :-) ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2003-09-25 14:48 Message: Logged In: YES user_id=53034 The hardcoding of our base path is irritating and somewhat ugly, but I don't see a better solution at this point in time. I don't see the point in this patch until the oprofile binaries are properly relocatable. So I'm going to close this as LATER. Marc, if you can think of a nice solution to the oprof_start problem, we'd like to hear it. Note that some people are using oprof_start via sudo, so we can't simply search $PATH for the programs that oprof_start calls out to. ---------------------------------------------------------------------- Comment By: Philippe Elie (phil_e) Date: 2003-09-24 22:15 Message: Logged In: YES user_id=318973 it's not sufficient afaics, if I remove previously installed version, apply you patch autogen.sh && configure && make && make install exec_prefix=/foo then oprof_start can't find opcontrol to start the profiler because we use OP_BINDIR in oprof_start. opcontrol contains also a hard-coded PATH= but it shouldn't matter (except it's probably a problem to use hard code path). I've some doubt make install prefix= will works too for some related problem. John, do we want to fix this ? regards, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 |
From: SourceForge.net <no...@so...> - 2003-09-25 15:30:53
|
Bugs item #811978, was opened at 2003-09-24 19:11 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 Category: None Group: None Status: Open Resolution: Later Priority: 5 Submitted By: Marc Herbert (marchash) Assigned to: Nobody/Anonymous (nobody) Summary: configure expands exec_prefix (stow issue) Initial Comment: Extract from configure shipped with 0.6.1: # Installation directory options. # These are left unexpanded so users can "make install exec_prefix=/foo" # and all the variables that are supposed to be based on exec_prefix # by default will actually change. # Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' ---- This is theory. Unfortunately in practice the current "config.h fixups" in configure expand $exec_prefix and spoil this. The attached patch (successfully tested with 0.6.1) enables the "stowing" of oprofile. ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2003-09-25 15:30 Message: Logged In: YES user_id=53034 I didn't realise stow could do that. Can you please send the patch to le...@mo... ---------------------------------------------------------------------- Comment By: Marc Herbert (marchash) Date: 2003-09-25 15:20 Message: Logged In: YES user_id=447685 The problem is that... you did not fully read my report :-) My patch does NOT aim at making oprofile binaries really relocatable, because the tool "stow" is enough to enable relocation of un-relocatable binaries, thanks to automated creation of symbolic links. Sorry, this patch is not the great relocation fix you were expecting, but still, it provides compatibility with the great, simple and widespread "stow" primitive package management tool. Have a look at stow here: <http://www.gnu.org/software/stow/manual.html> Stow can perfectly cope with the hardcoding of paths in binaries, as long as the _Makefiles_ stay clean. Thus my small patch. I suggest your give stow a try, it's as simple as: make install prefix=/usr/local/stow/oprofile-0.6.1-b4 cd /usr/local/stow/ stow --delete oprofile-0.6.1-b3 # disable b3 version stow oprofile-0.6.1-b4 # enable b4 version The commands above work only... with my patch :-) ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2003-09-25 12:48 Message: Logged In: YES user_id=53034 The hardcoding of our base path is irritating and somewhat ugly, but I don't see a better solution at this point in time. I don't see the point in this patch until the oprofile binaries are properly relocatable. So I'm going to close this as LATER. Marc, if you can think of a nice solution to the oprof_start problem, we'd like to hear it. Note that some people are using oprof_start via sudo, so we can't simply search $PATH for the programs that oprof_start calls out to. ---------------------------------------------------------------------- Comment By: Philippe Elie (phil_e) Date: 2003-09-24 20:15 Message: Logged In: YES user_id=318973 it's not sufficient afaics, if I remove previously installed version, apply you patch autogen.sh && configure && make && make install exec_prefix=/foo then oprof_start can't find opcontrol to start the profiler because we use OP_BINDIR in oprof_start. opcontrol contains also a hard-coded PATH= but it shouldn't matter (except it's probably a problem to use hard code path). I've some doubt make install prefix= will works too for some related problem. John, do we want to fix this ? regards, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 |
From: SourceForge.net <no...@so...> - 2003-10-23 17:38:03
|
Bugs item #811978, was opened at 2003-09-24 19:11 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marc Herbert (marchash) Assigned to: Nobody/Anonymous (nobody) Summary: configure expands exec_prefix (stow issue) Initial Comment: Extract from configure shipped with 0.6.1: # Installation directory options. # These are left unexpanded so users can "make install exec_prefix=/foo" # and all the variables that are supposed to be based on exec_prefix # by default will actually change. # Use braces instead of parens because sh, perl, etc. also accept them. bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' ---- This is theory. Unfortunately in practice the current "config.h fixups" in configure expand $exec_prefix and spoil this. The attached patch (successfully tested with 0.6.1) enables the "stowing" of oprofile. ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2003-10-23 15:47 Message: Logged In: YES user_id=53034 Fixed in 0.7 release ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2003-09-25 15:30 Message: Logged In: YES user_id=53034 I didn't realise stow could do that. Can you please send the patch to le...@mo... ---------------------------------------------------------------------- Comment By: Marc Herbert (marchash) Date: 2003-09-25 15:20 Message: Logged In: YES user_id=447685 The problem is that... you did not fully read my report :-) My patch does NOT aim at making oprofile binaries really relocatable, because the tool "stow" is enough to enable relocation of un-relocatable binaries, thanks to automated creation of symbolic links. Sorry, this patch is not the great relocation fix you were expecting, but still, it provides compatibility with the great, simple and widespread "stow" primitive package management tool. Have a look at stow here: <http://www.gnu.org/software/stow/manual.html> Stow can perfectly cope with the hardcoding of paths in binaries, as long as the _Makefiles_ stay clean. Thus my small patch. I suggest your give stow a try, it's as simple as: make install prefix=/usr/local/stow/oprofile-0.6.1-b4 cd /usr/local/stow/ stow --delete oprofile-0.6.1-b3 # disable b3 version stow oprofile-0.6.1-b4 # enable b4 version The commands above work only... with my patch :-) ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2003-09-25 12:48 Message: Logged In: YES user_id=53034 The hardcoding of our base path is irritating and somewhat ugly, but I don't see a better solution at this point in time. I don't see the point in this patch until the oprofile binaries are properly relocatable. So I'm going to close this as LATER. Marc, if you can think of a nice solution to the oprof_start problem, we'd like to hear it. Note that some people are using oprof_start via sudo, so we can't simply search $PATH for the programs that oprof_start calls out to. ---------------------------------------------------------------------- Comment By: Philippe Elie (phil_e) Date: 2003-09-24 20:15 Message: Logged In: YES user_id=318973 it's not sufficient afaics, if I remove previously installed version, apply you patch autogen.sh && configure && make && make install exec_prefix=/foo then oprof_start can't find opcontrol to start the profiler because we use OP_BINDIR in oprof_start. opcontrol contains also a hard-coded PATH= but it shouldn't matter (except it's probably a problem to use hard code path). I've some doubt make install prefix= will works too for some related problem. John, do we want to fix this ? regards, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=811978&group_id=16191 |