Could you at the very least test it yourself unstead of just assuming it will "likely" not work? I wouldn't be doing it myself this way if it wouldn't work. The only time it won't find libraries is if you don't set your LD_LIBRARY_PATH approprietely: export LD_LIBRARY_PATH=~/.local/lib:$LD_LIBRARY_PATH Again, we have .bashrc or .zshrc for that. The other possibility is that header files are hardcoded to something like "#include </usr/include/stdio.h>" rather than "#include <stdio.h>", but you really have to be the dumbest developer on the face of the Earth to even do that. On 2023年08月17日 21:30, Doug Newgard wrote:
On Fri, 18 Aug 2023 11:00:37 +0900 "lain." <lain@fair.moe> wrote:
This is how I have set it up: /usr/bin = systemwide binaries /usr/lib = systemwide libraries ~/.local/bin = user binaries ~/.local/lib = user libraries
I don't really like to use /usr/local/* on Linux, because it's not as portable as just /usr. I use it only in FreeBSD and OpenBSD, simply because it's the default behavior there.
If you compile from source (includes AUR): ./configure --prefix="~/.local" make DESTDIR="~/.local" install
If directly from the pacman repo's: pacman -S android-ndk -r ~/.local -b /var/lib/pacman The one downside of that is that it'll install for example "android-tools" under ~/.local/usr/bin rather than ~/.local/bin though, but with a bit of manual labor, you can correct that.
Then in your .bashrc or .zshrc: export PATH=~/.local/bin:$PATH
This way you can install multiple versions of software, and binaries in ~/.local will take preference over those in /usr, and you can always just run /usr/bin/whatever if you want to run the systemwide version instead.
And none of them are likely to work. It'll have no way to find it's libraries or other resources. You CANNOT use pacman for something like this.
-- lain.