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@xxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
