On some operating systems os_get_runtime_executable_path() can fail. On some systems it is almost certain, such as OpenBSD/amd64 with the standard kernel. On HP/UX os_get_runtime_executable_path() is just a stub function which always returns a nonsense string.
If sbcl isn't able to find the executable path using the os-dependent method then it may still be possible to find a path to the executable on non-win32 OSes using argv[0], searching the PATH environment variable if necessary. This method is somewhat error-prone, so it would be better to add a new function to check the build_id, and then to call it both when checking for an embedded core on startup and when saving an executable core from save-lisp-and-die.
Attached is a patch which does this, as well as removing the now-superfluous warning when the NetBSD/OpenBSD os_get_runtime_executable_path() fails.
Attached is the previous patch, updated to account for how os_get_
A flag is added to o_g_r_e_p() to request that the returned path is externally usable, ie: suitable for use in a shebang line.
The NetBSD/OpenBSD and SunOS implementations, which return a magic path in /proc that is only valid for the current process, are changed to return NULL if the flag is true. All the other OS's implementations look fine just by reading the code but I haven't actually checked any of them.
Change the code in main() to always try to save the argv[0] derived runtime path, in case o_g_r_e_p() fails later on when an external path is needed.
Change the *CORE-PATHNAME* setting code to try the saved argv[0] derived path if O-G-R-E-P fails.
While working on this I noticed what may be a small memory leak in the *CORE-PATHNAME* setting code in src/code/