4 ms·

Isn't that just statically linking binaries? Couldn't I do that manually too very easily? Serious question. Otherwise, if it's really relocating binaries, then

by X4 13y ago

Isn't that just statically linking binaries? Couldn't I do that manually too very easily? Serious question. Otherwise, if it's really relocating binaries, then it's awesomse, BUT I definately want to know MORE about the 'caching' part. That comes short in the docs.

mwilliamson 13y ago
In my experience, a lot of Linux programs aren't straightforward to compile statically. Having said that, that might just be my ineptitude! Which bit of the caching isn't clear? If you're happy that whack creates relocatable versions, then the caching works just by copying the output directory into ~/.cache, and then copying that directory to the target on subsequent installations. The exact details of how programs are made relocatable are under "How does Whack work?" in the README.
- X4 13y ago
  Thank you, that answers my question No you're right, not all binaries can be statically linked easily, it's very tedious in these cases. Oh, no I hoped that something performance related is happening when you said cache, like tuning the binary, predictive read-ahead streaming of the binary to memory, or something like that. I didn't know that it's a copy operation.
- justincormack 13y ago
  Some programs rely on dynamic libraries for modules so you can't, but the main issue is glibc is not designed to support static linking. Use eg Musl as your libc and it is fine.
0x0 13y ago
I'm guessing this will also help with hardcoded paths for config files and so on.
- mwilliamson 13y ago
  Yes, so long as the hard-coded path for the the config file is within the output directory, the program will find the right config file for that particular installation. You still won't be able to put the config file in an arbitrary location, but at least you can have isolated instances of the program with isolated config files.
  - justincormack 13y ago
    You could bind mount new copies of config files in other locations, but you have to know where they are...

by X4 13y ago

mwilliamson 13y ago

In my experience, a lot of Linux programs aren't straightforward to compile statically. Having said that, that might just be my ineptitude! Which bit of the caching isn't clear? If you're happy that whack creates relocatable versions, then the caching works just by copying the output directory into ~/.cache, and then copying that directory to the target on subsequent installations. The exact details of how programs are made relocatable are under "How does Whack work?" in the README.

X4 13y ago
Thank you, that answers my question No you're right, not all binaries can be statically linked easily, it's very tedious in these cases. Oh, no I hoped that something performance related is happening when you said cache, like tuning the binary, predictive read-ahead streaming of the binary to memory, or something like that. I didn't know that it's a copy operation.
justincormack 13y ago
Some programs rely on dynamic libraries for modules so you can't, but the main issue is glibc is not designed to support static linking. Use eg Musl as your libc and it is fine.

0x0 13y ago

I'm guessing this will also help with hardcoded paths for config files and so on.

mwilliamson 13y ago
Yes, so long as the hard-coded path for the the config file is within the output directory, the program will find the right config file for that particular installation. You still won't be able to put the config file in an arbitrary location, but at least you can have isolated instances of the program with isolated config files.
- justincormack 13y ago
  You could bind mount new copies of config files in other locations, but you have to know where they are...