Roderich, thanks for the quick reply! > I consulted the rakubrew.org page, but failed to understand the shim mode. > What does it do? And what role plays the PAR packed rakubrew executable in > "forwards its call to other programs"?
In shim mode, rakubrew creates a copy of / symlink to itself for each executable that can be found in any Rakudo installation it manages. When any of those copies / links is called, rakubrew determines, which Rakudo installation is currently active and then "exec"s the respective executable in that installation. This is works fine in general. On Windows and MacOS rakubrew is packaged with PAR. This has the conseqence, that the executable rakubrew ends up "exec"ing inherits the environment of rakubrew. That environment contains the changes of PAR. > This executable will inherit the DYLD_LIBRARY_PATH (which has a > component that points into the cache directory where the packed executable > has extracted itself into). That matches my observations. What I think happens is this: A user adds a folder, e.g. "/opt/local/lib", to DYLD_LIBRARY_PATH. One of the libraries in that folder is also present in the PAR archive. The version of the library in the PAR archive takes precedence and thus a different library from the one the user expects is used. > > Thus I'd like to make Rakubrew reset the environment to its original state > > before doing the final "exec". > > Could this cause problems for the packed rakubrew executable itself? I > don't think so, though I don't know the details of how MacOS and Windows > load DLLs. On Linux the dynamic loader reads and caches environment > variables, in particular LD_LIBRARY_PATH, at the start of program > execution. Hence changes to LD_LIBRARY_PATH during the program's execution > don't have any effect (for the program itself). I thought about this as well. My initial thought was that I could pass a modified / cleaned up environment to "exec" itself, at least the C function execvpe has a parameter to do just that. But I didn't find a way to do so in Perl. So my best guess was to just modify %ENV right before the call to "exec" and hope everything would work out. Did I understand correctly, that you also have no better idea than heuristically trying to bring ENV back to its original state right before doing "exec"? Patrick
