Are the executables run with their full path for the bootstrap compilers?
If so, could it preferentially use that from argv[0] (like sshd does when
it needs to know its own path for reexec), and fallback to
/usr/local/whatever if there's no / in argv[0]?
--
Sent from a phone, apologies for poor formatting.
On 29 October 2021 04:48:13 Greg Steuck <gne...@openbsd.org> wrote:
"Theo de Raadt" <dera...@openbsd.org> writes:
Wind R <oct...@protonmail.com> wrote:
1. OpenBSD doesn't have a syscall that returns the current path to the
executable file of the process, which adb and fastboot both use.
This system call is impossible. It is not possible to convert an inode
to a path cheaply. A variety of systems have this, and it either (very
often) or (upon occasion) lies. When it lies, the applications take a
variety of bullshit strategies to cope, pretty much all of them wrong.
It appears this idea came from Windows, where you can install
applications in various directories. Our ports applications are always
installed in /usr/include Is that difficult to understand?
Should we make this system call and make it always lie or fail, to demonstrate
the issue to the community, or can they finally understand that OpenBSD
ports are *always installed to the same place*?
I ran into this head-on with ghc. The problem here is not the eventual
installation, but rather the development builds. These aren't installed
into the final destination when building bootstrap compilers. A great
answer to this is to pass paths explicitly. Unfortunately the layers of
stuff make this into a non-trivial complication and otherwise patient
people give up: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6263
This is not immediately actionable, just sharing the kinds of things
that get side-tracked.
Thanks
Greg
