Hi,
I am having a problem building pike in a fakeroot/sandbox'ed environment and *additionally* dump the pike modules.
(to avoid those problems you surely have heard about hundred times when building in a fakeroot and then try to run a pike application using a module: /usr/lib/pike/.../.../whatever.pmod.o:-: Warning: Decode failed: Failed to decode program)
The problem I am having is, pike seems to be able to dump the modules when installing in a fakeroot environment from what I can read in the install scripts but it cannot do it without violating the sandbox (e.g. writing outside the fakeroot).
In short, I do the following (after pike was built using make CONFIGUREARGS="..." etc.):
sed -i s/rm(mod+".o");/{}/ for install.pike, which results in the following:
--- install.pike.orig +++ install.pike @@ -1096,7 +1096,7 @@ rm("dumpmodule.log");
foreach(to_dump, string mod) - rm(mod+".o"); + {}
// Dump 25 modules at a time
I need to do this, because otherwise the sandbox is violated since pike directly wants to do some action in /usr/lib/...
Then I use the following command to install pike:
make INSTALLARGS="--traditional" buildroot="${D}" install
("${D}" being the virtual "/") Because of the change to install.pike, the modules aren't dumped automagically, and to be honest, I feel a bit lost now how I can dump the modules to avoid those fakeroot/decode problems with the modules, but without violating the sandbox.
Thanks in advance for your answers,
At least I haven't seen that problem a hundred times. I can imagine there are problems if pike is installed in one location, tar'ed together and then extracted in a different place. That's because absolute paths normally are written in the dumped files, and that the pike binary is modified to contain an absolute path to the master.
(The NT installation variant contains relocation code to avoid absolute paths since, if I remember correctly, modules can't be dumped at installation time for some reason. Anyway, that stuff doesn't work entirely well.)
I don't understand how your fix solves anything. If the files that pike tries to remove there are in the wrong place then the dumping later on will fail much more, and pretty much the whole setup of the installed tree too, I suspect.
It looks rather like the install prefix to install.pike is incorrect. You can control it with an argument prefix=a/good/place to the installer.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-12-09 20:42: Subject: How to dump pike modules in a fakeroot/sandbox environment?
Hi,
I am having a problem building pike in a fakeroot/sandbox'ed environment and *additionally* dump the pike modules.
(to avoid those problems you surely have heard about hundred times when building in a fakeroot and then try to run a pike application using a module: /usr/lib/pike/.../.../whatever.pmod.o:-: Warning: Decode failed: Failed to decode program)
The problem I am having is, pike seems to be able to dump the modules when installing in a fakeroot environment from what I can read in the install scripts but it cannot do it without violating the sandbox (e.g. writing outside the fakeroot).
In short, I do the following (after pike was built using make CONFIGUREARGS="..." etc.):
sed -i s/rm(mod+".o");/{}/ for install.pike, which results in the following:
--- install.pike.orig +++ install.pike @@ -1096,7 +1096,7 @@ rm("dumpmodule.log");
foreach(to_dump, string mod)
rm(mod+".o");
{}// Dump 25 modules at a time
I need to do this, because otherwise the sandbox is violated since pike directly wants to do some action in /usr/lib/...
Then I use the following command to install pike:
make INSTALLARGS="--traditional" buildroot="${D}" install
("${D}" being the virtual "/") Because of the change to install.pike, the modules aren't dumped automagically, and to be honest, I feel a bit lost now how I can dump the modules to avoid those fakeroot/decode problems with the modules, but without violating the sandbox.
Thanks in advance for your answers,
-- Rainer Groesslinger rainer.groesslinger@gmx.net
/ Brevbäraren
At least I haven't seen that problem a hundred times. I can imagine there are problems if pike is installed in one location, tar'ed together and then extracted in a different place. That's because absolute paths normally are written in the dumped files, and that the pike binary is modified to contain an absolute path to the master.
and that is my problem, but see below. (btw. "a hundred times" may a bit overkill but I found a few messages about it in the archives and also google had some results on this problem)
(The NT installation variant contains relocation code to avoid absolute paths since, if I remember correctly, modules can't be dumped at installation time for some reason. Anyway, that stuff doesn't work entirely well.)
I don't understand how your fix solves anything. If the files that pike tries to remove there are in the wrong place then the dumping later on will fail much more, and pretty much the whole setup of the installed tree too, I suspect.
It looks rather like the install prefix to install.pike is incorrect. You can control it with an argument prefix=a/good/place to the installer.
I am already using prefix... The problem is this: If I use prefix=/usr and build it pike violates the sandbox because it directly wants to dump in /usr/... that's why I modify install.pike. If I use [/my/fakeroot/path]/usr as a prefix and keep install.pike as it is, dumping the module works, but the pike binary doesn't because it wants to run [/my/fakeroot/path]/.../pike which afterwards, of course, doesn't exist anymore. (and if it still does, that's not a satisfying solution either ;)
So my problem with pike and a fakeroot/sandbox environment is in other words: 1. I can only solve the sandbox issue by modifying install.pike (like shown in my original mail) but then the modules aren't dumped and thus, don't work, or 2. only fix the module problem by using the virtual path + /usr as the prefix, dumping the modules works then, but e.g. the pike binary is still referencing to the virtual builddir.
But I can't find a solution to solve both. (Note: The files are *not* tar'ed and moved to another location/system or whatever, everybody using fakeroot+sandbox has that problem, I just can't find a solution for it).
btw. "buildroot" was the virtual path in all cases.
If the files aren't moved to another location, how can it become a problem that the pike binary wants to load [/my/fakeroot/path]/lib/master.pike?
For the relocation problem I see two solutions:
1. Always use the relocation system (see the PIKE_MODULE_RELOC stuff in the master and install.pike). 2. Fix the module dumper to read/write the dumps to one location while compiling in the path to another. install.pike must also be fixed to patch the binary with a fake path to the master.
The first alternative is ultimately the best and probably also the easiest one for you to implement since it's basically enough to add an argument PIKE_MODULE_RELOC=1 to install.pike.
But as I said, it doesn't always work well. The problem is code that uses __FILE__ in odd ways, since it will expand to a path like "/${PIKE_MODULE_PATH}/foo/bar.pike", and all path related functions can't handle the initial part correctly. This can be a compatibility problem, but code that fails on it will fail on NT anyway, so that code should be fixed anyway.
A third option is of course to run the installation program at installation time instead of at build time, but that takes extra time at installation instead. (In case we're talking Debian here, it does that for elisp packages. I don't like it at all since it takes a whole lot of time if you got many elisp packages and emacs flavors installed.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-12-11 18:28: Subject: Re: How to dump pike modules in a fakeroot/sandbox environment?
At least I haven't seen that problem a hundred times. I can imagine there are problems if pike is installed in one location, tar'ed together and then extracted in a different place. That's because absolute paths normally are written in the dumped files, and that the pike binary is modified to contain an absolute path to the master.
and that is my problem, but see below. (btw. "a hundred times" may a bit overkill but I found a few messages about it in the archives and also google had some results on this problem)
(The NT installation variant contains relocation code to avoid absolute paths since, if I remember correctly, modules can't be dumped at installation time for some reason. Anyway, that stuff doesn't work entirely well.)
I don't understand how your fix solves anything. If the files that pike tries to remove there are in the wrong place then the dumping later on will fail much more, and pretty much the whole setup of the installed tree too, I suspect.
It looks rather like the install prefix to install.pike is incorrect. You can control it with an argument prefix=a/good/place to the installer.
I am already using prefix... The problem is this: If I use prefix=/usr and build it pike violates the sandbox because it directly wants to dump in /usr/... that's why I modify install.pike. If I use [/my/fakeroot/path]/usr as a prefix and keep install.pike as it is, dumping the module works, but the pike binary doesn't because it wants to run [/my/fakeroot/path]/.../pike which afterwards, of course, doesn't exist anymore. (and if it still does, that's not a satisfying solution either ;)
So my problem with pike and a fakeroot/sandbox environment is in other words:
- I can only solve the sandbox issue by modifying install.pike (like
shown in my original mail) but then the modules aren't dumped and thus, don't work, or 2. only fix the module problem by using the virtual path + /usr as the prefix, dumping the modules works then, but e.g. the pike binary is still referencing to the virtual builddir.
But I can't find a solution to solve both. (Note: The files are *not* tar'ed and moved to another location/system or whatever, everybody using fakeroot+sandbox has that problem, I just can't find a solution for it).
btw. "buildroot" was the virtual path in all cases.
-- Rainer Groesslinger rainer.groesslinger@gmx.net
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum -
Rainer Groesslinger