What is the status of PIKE_MODULE_RELOC? In the 7.4 master it's disabled with the comment "currently broken" but not in 7.6 or 7.7. Still, it's being used in 7.4 on Windows, right?
I tried enabling it (--with-relocatable-dumped-modules) in a test build of 7.4 on Darwin but didn't succeed which wasn't surprising given the comment above. However, not even in a shiny new 7.7 build could I get it working:
ceylon:pike-reloc $ ./moved77/pike/7.7.21/bin/pike "Couldn't load master program from /tmp/pike-reloc/install77/pike/7.7.21/lib/master.pike.\n"
Oh well, at least providing the paths explicitly should work:
ceylon:pike-reloc $ ./moved77/pike/7.7.21/bin/pike -m /tmp/pike-reloc/moved77/pike/7.7.21/lib/master.pike -M /tmp/pike-reloc/moved77/pike/7.7.21/lib/modules/ -P /tmp/pike-reloc/moved77/pike/7.7.21/lib/modules/ -I /tmp/pike-reloc/moved77/pike/7.7.21/include/ Could not resolv Getopt. (Perhaps the installed pike tree has been moved.) /tmp/pike-reloc/moved77/pike/7.7.21/lib/master.pike:2388: master()->__lambda_65601_2_line_2385("Getopt",UNDEFINED)
What am I missing here?
Also, a related question is what the whole point of the Master Cookie is? Overcome limitations that one cannot find the path of the currently executing process? At least on Darwin that can be solved with some system calls such as NSModuleForSymbol(), and maybe other systems have similar calls nowadays?
Before trying to get PIKE_MODULE_RELOC working again, I would recommend rewriting (un)relocate_module to be based on lib_prefix instead of pike_module_path. That would avoid both bugs and gray hairs, since lib_prefix is A) a single directory, and B) not changed at runtime... (Probably the kluge in handle_import could be removed as well.)
Regarding what you are missing, it is that the Getopt module is used to parse your -M arguments, and so they will not be used when resolving the Getopt module itself. If Getopt is not avaiable in the builtin module path, you need to set the environment variable $PIKE_MODULE_PATH.
Thanks. I'm getting more confused by the minute, though. Fixing the whole PIKE_MODULE_RELOC stuff won't make the whole Pike installation fully relocatable anyway, right? We still have to provide paths for the binary, the master and the include directories when Pike is started which in turn defeats the idea I had about a Pike tree that could be dragged-and-dropped anywhere.
Having the Pike process query the OS for its location on disk also fails if it's been hard-linked to a different place (like the Roxen installer does). Grmbl.
On Sun, Jun 05, 2005 at 03:55:01PM +0000, Jonas Walldén @ Pike developers forum wrote:
Having the Pike process query the OS for its location on disk also fails if it's been hard-linked to a different place (like the Roxen installer does). Grmbl.
could not any application that hardlinks the pike binary provide the necesary path in its start script?
anybody running pike the normal way will run it from the default location, those hardlinking know what they are doing and should be able to handle that correctly.
alternatively why not do both? that way things continue to work as usual as long as you do not relocate, but you gain the option of relocating if you are willing to give up the hardlink advantage.
greetings, martin.
Yes, what Roxen does I can modify :-) but it's conceivable that other apps would require updating to pass additional parameters when starting a hard-linked Pike.
To solve that I'd have to rely on the Master Cookie first; only if it's invalid I'd resort to query the OS for the current location. This in turn may have weird side-effects if the Pike installation is duplicated instead of moved as it would find the original tree (that probably only concerns developers though).
By the way, this is the code that locates the process binary on Darwin (minus error checking). If the same can be achieved on Linux etc I'm interested in learning about it.
#include <mach-o/dyld.h> NSSymbol s = NSLookupAndBindSymbol("_main"); NSModule m = NSModuleForSymbol(s); char *path = NSNameOfModule(m);
I just tested dladdr() and it produces the same result as the dyld code I posted. It's also available in Linux and Solaris so we have a winner!
PIKE_MODULE_RELOC fixes relocatable dumped modules (hence the name). You still have paths in the master, and in the main binary, which need modifying when you move the installation to a new path.
Yeah, it's slowly coming back to me. Windows modules need to be relocatable not because the Pike tree can be moved by the user after installation but because they must be dumped before inclusion in the InstallShield package.
Yes. The paths in the master and the main binary OTOH are patched by a small C program which is run by the InstallShield project. All in the great effort not to run any Pike programs during the installation, to avoid having any DOS windows pop up... ;-)
My windows installer dumps the modules during install, but runs Pike as "hidden" to avoid popups. Instead it opens a GTK window with a progress bar.
pike-devel@lists.lysator.liu.se
-
Jonas Walld�n ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr -
Martin Nilsson (DivX Inc.) ＠ Pike (-) developers forum