Re: Hard coded paths in csc and relocatable chicken
or use proot or some other kind of chroot or container or mount proot might be simplest, depending on your deployment options
Re: Hard coded paths in csc and relocatable chicken
HI Mario, Yes, static csc, csi etc would work but the calls in csc to other chicken tools would need to use $PATH or I would be up against the same issue. I'll try some of the other suggestions. I did look at csc.scm but I have not been able to figure out where the hard-coded paths are created. Maybe it is in the "C" compilation step? The classic solution for this in the scripting world is to find the path to the running executable and use that to find the child executables: I.e. if csc used (pathname-directory (car (argv to prefix as a path to the other executable calls or an env var to give end users control then I'd be enabled. Thanks, Matt -=- On Fri, May 21, 2021 at 10:58 AM Mario Domenech Goulart < ma...@parenteses.org> wrote: > Hi Matt, > > On Thu, 20 May 2021 15:04:16 -0700 Matt Welland > wrote: > > > As mentioned in the coding jam I put together a chicken bundle including > the iup egg ready to go outside the box. It turns out that my assertion that > > it worked was wrong. I tested by running csi and was able to load iup > and create a button and I assumed that if this worked then so would > compilation > > with csc. Not so. While a little script hackery could swizzle the full > paths in the .info files for eggs I don't think there is any way to change > the > > paths in compiled binaries such as csc. > > > > I really would like to be able to make a relocatable build system to > enable us to use chicken in our ever more constrained compute environment. > > > > The directories are all pointing to the original install directory. E.g. > >> strings csc | less > > ... > > _edata > > __bss_start > > _end > > /home/matt/buildall/ck5.2/lib > > GLIBC_2.3 > > GLIBC_2.2.5 > > > > Any suggestions or ideas on how to work around this? > > Would static linking be an acceptable solution in this case? > > All the best. > Mario > -- > http://parenteses.org/mario > > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
Re: Hard coded paths in csc and relocatable chicken
Hi Matt, On Thu, 20 May 2021 15:04:16 -0700 Matt Welland wrote: > As mentioned in the coding jam I put together a chicken bundle including the > iup egg ready to go outside the box. It turns out that my assertion that > it worked was wrong. I tested by running csi and was able to load iup and > create a button and I assumed that if this worked then so would compilation > with csc. Not so. While a little script hackery could swizzle the full paths > in the .info files for eggs I don't think there is any way to change the > paths in compiled binaries such as csc. > > I really would like to be able to make a relocatable build system to enable > us to use chicken in our ever more constrained compute environment. > > The directories are all pointing to the original install directory. E.g. >> strings csc | less > ... > _edata > __bss_start > _end > /home/matt/buildall/ck5.2/lib > GLIBC_2.3 > GLIBC_2.2.5 > > Any suggestions or ideas on how to work around this? Would static linking be an acceptable solution in this case? All the best. Mario -- http://parenteses.org/mario
Re: Hard coded paths in csc and relocatable chicken
On Fri, 21 May 2021 11:00:35 -0400 Marc Feeley wrote: >> On May 21, 2021, at 8:58 AM, Théo Cavignac wrote: >> >> I have been interested in this problem for other reasons, mainly >> because I was interested in the possibility of installing eggs in >> userspace while Chicken was installed through distro package manager >> (thus in root). >> >> Anyway, in the current states of the compiler it appears that the >> whole build process of Chicken is built around the assumption of a >> fixed install path. >> >> The dust project (https://sr.ht/~evhan/dust/) solved this by putting >> a placeholder 256 * "X" instead of the path in binaries, then >> editing the binaries in place when installing in your location. >> >> I don't know how it would fit in your use case and it is definitely >> hacky but it works. > > A similar hack that is used by Gambit is to put a long sequence of > ./././ etc in the paths embedded in the binary and patching the binary > when it is installed. The benefit of that approach is that the path > in the unpatched binary can be the path where the binary is usually > installed. That's a clever hack. Thanks for sharing, Marc. All the best. Mario -- http://parenteses.org/mario
Re: Hard coded paths in csc and relocatable chicken
On 5/20/21 23:04, Matt Welland wrote: As mentioned in the coding jam I put together a chicken bundle including the iup egg ready to go outside the box. It turns out that my assertion that it worked was wrong. I tested by running csi and was able to load iup and create a button and I assumed that if this worked then so would compilation with csc. Not so. While a little script hackery could swizzle the full paths in the .info files for eggs I don't think there is any way to change the paths in compiled binaries such as csc. I really would like to be able to make a relocatable build system to enable us to use chicken in our ever more constrained compute environment. The directories are all pointing to the original install directory. E.g. > strings csc | less ... _edata __bss_start _end /home/matt/buildall/ck5.2/lib GLIBC_2.3 GLIBC_2.2.5 Any suggestions or ideas on how to work around this? Thanks, Matt -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson. Hey Matt, Take a look at `cenv`[0] -- it may or may not already do what you're looking for, but it uses these[1] environment variables, that may also be useful to you. [0]: https://github.com/ursetto/cenv [1]: https://wiki.call-cc.org/man/5/Extension%20tools#changing-the-repository-location Regards, André Sá
Re: Hard coded paths in csc and relocatable chicken
On Fri 21 May 2021 at 14:58, Théo Cavignac wrote: > The dust project (https://sr.ht/~evhan/dust/) solved this by putting a > placeholder 256 * "X" instead of the path in binaries, then editing the > binaries in place when installing in your location. if you build the binary using nix, the paths will be long already (eepitch-shell) (eepitch-kill) (eepitch-shell) nix-shell -p chicken cat $(which csi) strings \ /nix/store/x8i2vgnvdd5vr0njicpav6bvzws4l5ps-chicken-5.2.0/bin/.csi-wrapped \ | grep nix/store /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/ld-linux-x86-64.so.2 /nix/store/x8i2vgnvdd5vr0njicpav6bvzws4l5ps-chicken-5.2.0/lib:/nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib /nix/store/x8i2vgnvdd5vr0njicpav6bvzws4l5ps-chicken-5.2.0
Re: Hard coded paths in csc and relocatable chicken
> On May 21, 2021, at 8:58 AM, Théo Cavignac wrote: > > Hi Matt, > > I have been interested in this problem for other reasons, mainly because I > was interested in the possibility of installing eggs in userspace while > Chicken was installed through distro package manager (thus in root). > > Anyway, in the current states of the compiler it appears that the whole build > process of Chicken is built around the assumption of a fixed install path. > > The dust project (https://sr.ht/~evhan/dust/) solved this by putting a > placeholder 256 * "X" instead of the path in binaries, then editing the > binaries in place when installing in your location. > > I don't know how it would fit in your use case and it is definitely hacky but > it works. > > Cheers, > > Théo > A similar hack that is used by Gambit is to put a long sequence of ./././ etc in the paths embedded in the binary and patching the binary when it is installed. The benefit of that approach is that the path in the unpatched binary can be the path where the binary is usually installed. Marc
Re: Hard coded paths in csc and relocatable chicken
Hi Matt, I have been interested in this problem for other reasons, mainly because I was interested in the possibility of installing eggs in userspace while Chicken was installed through distro package manager (thus in root). Anyway, in the current states of the compiler it appears that the whole build process of Chicken is built around the assumption of a fixed install path. The dust project (https://sr.ht/~evhan/dust/) solved this by putting a placeholder 256 * "X" instead of the path in binaries, then editing the binaries in place when installing in your location. I don't know how it would fit in your use case and it is definitely hacky but it works. Cheers, Théo Le 21/05/2021 à 00:04, Matt Welland a écrit : As mentioned in the coding jam I put together a chicken bundle including the iup egg ready to go outside the box. It turns out that my assertion that it worked was wrong. I tested by running csi and was able to load iup and create a button and I assumed that if this worked then so would compilation with csc. Not so. While a little script hackery could swizzle the full paths in the .info files for eggs I don't think there is any way to change the paths in compiled binaries such as csc. I really would like to be able to make a relocatable build system to enable us to use chicken in our ever more constrained compute environment. The directories are all pointing to the original install directory. E.g. > strings csc | less ... _edata __bss_start _end /home/matt/buildall/ck5.2/lib GLIBC_2.3 GLIBC_2.2.5 Any suggestions or ideas on how to work around this? Thanks, Matt -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
Hard coded paths in csc and relocatable chicken
As mentioned in the coding jam I put together a chicken bundle including the iup egg ready to go outside the box. It turns out that my assertion that it worked was wrong. I tested by running csi and was able to load iup and create a button and I assumed that if this worked then so would compilation with csc. Not so. While a little script hackery could swizzle the full paths in the .info files for eggs I don't think there is any way to change the paths in compiled binaries such as csc. I really would like to be able to make a relocatable build system to enable us to use chicken in our ever more constrained compute environment. The directories are all pointing to the original install directory. E.g. > strings csc | less ... _edata __bss_start _end /home/matt/buildall/ck5.2/lib GLIBC_2.3 GLIBC_2.2.5 Any suggestions or ideas on how to work around this? Thanks, Matt -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
