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.