dlopen() and (non-support in) MacPorts

[Mojca Miklavec]

Hi,

I'm maintaining the dvisvgm port which links against libgs and works
with ghostscript as expected.

But I also compile that binary as a standalone one, as part of TeX
Live (maybe MacTeX rings a bell, even though I'm not the one providing
MacTeX itself). That binary uses dlopen() to find libgs on the fly (if
one exists, else it just lacks certain functionality).

I just received a request from some user who is annoyed by the fact
that he always has to use
    dvisvgm --libgs="/opt/local/lib/libgs.9.22.dylib"
(which tries to open libgs from the specified location) and I would
like to find a better long-term solution for that problem.

Here's the relevant documentation:

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/dlopen.3.html

Setting
    export LD_LIBRARY_PATH="/opt/local/lib"
in .bash_profile works, but I'm not really happy with suggesting that
solution long term.

HB developers initially submitted a patch
    https://github.com/mgieseki/dvisvgm/issues/66
which makes sure that this standalone binary automatically finds
ghoscript from HB which works because /usr/local/lib is automatically
checked by macOS during dlopen(), but /opt/local/lib is not.

I'm not sure what I could do (in upstream) to provide a better
experience to users with ghoscripts from MacPorts and the standalone
binary from outside of MacPorts.

It would help if at least the /opt/local prefix was checked for
existence of the library. If the library was linked in the usual way,
I could probably use the rpath trick, but I assume this doesn't work
for dlopen().

Thank you,
    Mojca