Auto-detect ghostscript dynamic library (*.dylib) on macOS

[tobywf]

I'm running dvisvgm (TeX Live) 1.15.1, which comes with MacTeX 2016 on macOS Sierra 10.12.4. The binary isn't linked to ghostscript, and a common way to install it is via the popular Homebrew package manager (brew install ghostscript). This creates /usr/local/lib/libgs.9.dylib, which works fine when passed to dvisvgm --libgs or LIBGS, but isn't autodetected. A quick, permanent workaround is to symlink /usr/local/lib/libgs.9.dylib to /usr/local/lib/libgs.so.9.

To make it automatic, the ghostscript loader in get_libgs() could also look for libgs.<i>.dylib files on macOS only. I've held off on submitting a patch because you have no other macOS specific defines in the codebase so I don't know how to approach it. Maybe Richard Koch has some advice?

Alternatively, Homebrew could also produce a *.so symlink when ghostscript is installed. But that might have effects on other software, so I don't think it's a good idea - especially considering that multiple easy work-arounds exist.

Thanks for all the good work on dvisvgm, the clean codebase was truly a joy to browse!

[mgieseki]

Thanks for your suggestion and feedback. I'll gladly add further OS-specific checks to improve dvisvgm's functionality on macOS. Implementing the lookup of libgs.X.dylib should be pretty easy and similar to that of cyggs-X.dll under Cygwin. Unfortunately, I have no access to a Mac and therefore can't test the code in that environment myself. So if you have a working patch, feel free to post it here or send it to me by email. I guess, Richard Koch and Mojca Miklavec are also willing to answer further questions regarding Mac specifics of TeX Live.

[tobywf]

I've submitted pull request #67. It keeps the libgs.so.X loading behaviour (which still takes precedence), but also looks for libgs.X.dylib on macOS only. As I indicated in the PR, based on other includes in the texlive source tree, I believe __APPLE__ is the correct define to use.

There were several alternatives I considered:

1. As described above, look for shared objects and dynamic libraries of version 7/8/9. Probably the most compatible, but maybe overkill as libgs.7.dylib or libgs.8.dylib are probably super rare already. Plus those people must already be using the --libgs= option or LIBGS env var.
2. Look for shared objects of version 7/8/9, then finally look for the dynamic library of version 9.
3. Don't look for shared objects, just look for dynamic libraries of version 7/8/9 (similar to #if defined(__CYGWIN__), I'd just add a #elif defined(__APPLE__)). I don't know enough about ghostscript on macOS to say if this is a good idea.

Personally, I think approach no.2 is a good trade-off, and I'm happy to update the PR to use this method. But I've submitted the most compatible approach for now. Let me know what you think.

[mgieseki]

Great. Thanks for providing a working patch. I agree that keep looking for libgs.so.X is the best way to stay compatible with dvisvgm's recent behavior. Also, since MacOS supports both .so and .dylib libraries which seem to have different formats, preferring one to the other is probably not a good idea.

I adapted your patch a little bit because I'd rather avoid using additional scope blocks (just a personal preference). In order to keep the function short, I slightly adapted the DLLoader class, and replaced the string streams with strings. I hope that's OK with you. You'll find the recent changes in the tmp branch.

[mgieseki]

I merged your pull request and adapted the code that looks up the Ghostscript library a little bit. Thanks again for your work on this!

[natgrein]

Hello there,
I am not familiar with the updates on Git and am wondering how I could benefit from the patch mentionned above? I have the same problem that dvisvgm doesn't find the Ghostscript library on my MacOS.
Thank you in advance!
Nathan

[mgieseki]

Toby's patch has been merged into the sources but I haven't published a subsequent release yet due to lack of time and the need for some bugfixes still in the works. If you're familiar with compiling the sources on your own, you can build a binary that contains the latest additions.

[natgrein]

Thank you for your reply. Another question though: from the 'INSTALL' guidelines file I understood that if not specified, the executable of dvisvgm would be created in /usr/local/bin/
However, the current executable of dvisvgm that I have on my system is at /Library/TeX/texbin/
With the new install, won't I have some conflicts between the two versions? And won't TeX still try to use the old version instead of the newly installed version?
Those are surely trivial questions but I am new to this...
Thank you for your help
Nathan

[mgieseki]

Hi Nathan,
if you install several versions of the same command-line program, you must ensure that the desired one is called, e.g. by adapting the PATH variable or by renaming/removing the redundant ones. TeX itself doesn't require dvisvgm. It's a standalone utility usually called by the user. If you use it as part of a script, it's sufficient that the dvisvgm binary can be found through the search PATH.

The installation path can be changed with the --prefix switch of configure, e.g. ./configure --prefix=/Library/TeX/texbin/. However, I don't recommend that. It's better to keep the official binaries apart from your own builds.

[natgrein]

Thanks again Martin, after a little more search, I found this post https://tobywf.com/2017/04/build-dvisvgm-kpathsea-on-macos/ by toby where he provides a script for building dvisvgm and kpathsea on MacOS.
However, the ./configure fails to find the potrace.h library.
I didn't find a way to contact toby directly, so I use this space to try to reach him, I hope you don't mind...
Thank you for all the help.
Nathan

[mgieseki]

Sure, feel free to use this ticket for further conversation on the topic, or open a new one.

[tobywf]

@natgrein There's simple hack that I mentioned in the first comment:

A quick, permanent workaround is to symlink /usr/local/lib/libgs.9.dylib to /usr/local/lib/libgs.so.9

$ ln -s /usr/local/lib/libgs.9.dylib /usr/local/lib/libgs.so.9

Now dvisvgm should "find" the library :) I would recommend this approach over building from source, as it's way easier. Hope this helps!

Apologies for not reacting sooner, but I don't get notifications for old threads. In future, feel free to use @ mentions, which will definitely get my attention!

[kiryph]

libgs under macOS with MacTeX 2019

I am using MacTeX 2019 under macOS 10.14.6 with dvisvgm 2.6.3:

❯ which -a dvisvgm
/Library/TeX/texbin/dvisvgm

❯ dvisvgm --version
dvisvgm 2.6.3

❯ dvisvgm -l
bgcolor    background color special
color      complete support of color specials
dvisvgm    special set for embedding raw SVG snippets
em         line drawing statements of the emTeX special set
html       hyperref specials
papersize  special to set the page size
pdf        PDF hyperlink, font map, and pagesize specials
tpic       TPIC specials

❯ dvisvgm -h | grep libgs
      --libgs=filename          set name of Ghostscript shared library

ghostscript 9.27 is installed by MacTeX 2019

However, it looks like it does not provide a libgs.

Is this correct?

I have to install ghostscript with libgs e.g. with homebrew or macports.

[mgieseki]

As far as I know that's correct. However, Richard Koch wrote me a couple of months ago that he's going to add libgs to MacTeX-2020. So it should be available as of this year's release.
For the time being you need to install libgs separately, though.