From: Stuart Henderson Subject: Re: [WIP] OpenSCAD nightly port To: ports@openbsd.org Date: Wed, 1 Oct 2025 12:45:44 +0100 On 2025/09/30 18:50, Andrew Hewus Fresh wrote: > > * In cad/openscad, I patched out boost::dll::program_location similarly > > to how cad/prusaslicer did it, but running without the fully qualified > > path doesn't work, that value is not correct and it doesn't find > > share/openscad. > > My idea for this is to put the binary in libexec/openscad and a shell > script that execs it with the full path as bin/openscad: > > $ cat /usr/local/bin/openscad > #!/bin/sh > exec /usr/local/libexec/openscad "$@" > > See: > https://cvs.afresh1.com/cgi-bin/cvsweb/mystuff-openscad/cad/openscad/Makefile?rev=1.6&content-type=text/x-cvsweb-markup > > This seems to work, in that the "resource path" gets set correctly when > running an unqualified "openscad" that uses the PATH to find it, but it > seems like an ugly hack. Is there a better solution? This is quite common now. I think the increased use of this is largely coming from packaging/"bundling" methods used on various OS where some applications are distributed via methods that don't install them to shared system directories, instead a common base prefix per application, possibly installed in a user's home directory. These programs generally don't care about the exact path to the running binary (so it doesn't matter if it has been moved/renamed), they just want a best-efforts way to locate supporting files that are stored relative to the binary. I don't think there is really a better solution for OpenBSD. There are a few different options, possible methods include - hardcoding the expected package install location (may sometimes break tests) - if argv[0] isn't a full path, searching PATH and trying to locate the binary or, as you have found - wrapper script take your pick and add it to the growing collection of patches in ports to workaround these.