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 <gnezdo@openbsd.org> wrote:
> "Theo de Raadt" <deraadt@openbsd.org> writes:
>
>> Wind R <octeep@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
No comments:
Post a Comment