libgs not in expected path error

[juliangilbey]

I just got this error when trying to run doxygen.py for the first time on a Debian system:

$ ./doxygen.py ../../taskflow-test/doxygen/conf.py 
Traceback (most recent call last):
  File "<DIR>/m.css/documentation/./doxygen.py", line 57, in <module>
    import latex2svg
  File "<DIR>/m.css/documentation/../plugins/latex2svg.py", line 81, in <module>
    raise RuntimeError('libgs found by linker magic, but is not in {}'.format(' or '.join(prefixes)))
RuntimeError: libgs found by linker magic, but is not in /usr/lib or /usr/lib64

On Debian, libraries are now installed in a subdirectory of /usr/lib; on my system, it's /usr/lib/x86_64-linux-gnu/libgs.so.10. I'm unclear why doxygen.py doesn't just trust the value it's given?

[juliangilbey]

Oh, sorry, I see the problem: find_library doesn't return a path, just a filename :(

[mosra]

Oh well, not this again. You won't believe how much suffering I had with this so far :D

Fortunately most of that code is a workaround for a certain combination of ghostscript and dvisvgm versions that didn't work well, requiring a path to libgs being supplied explicitly via an env var. So in the optimistic case it wouldn't need to be used at all, and I would be able to eventually delete all this messy code.

The following patch looks at dvisvgm --version and if it's new enough, it just assumes that everything will work even without explicitly supplying a path to libgs. Can you try it on your end and confirm that it works?

diff --git a/plugins/latex2svg.py b/plugins/latex2svg.py
index 2df47865..e4a5c520 100755
--- a/plugins/latex2svg.py
+++ b/plugins/latex2svg.py
@@ -64,21 +64,34 @@ if not hasattr(os.environ, 'LIBGS') and not libgs:
 # 2023, remove after enough time passes if no similar case happens in other
 # distros
 elif '.so.10' in str(libgs):
+    # If dvisvgm seems to be at least 3.0, don't even attempt to find libgs and
+    # just assume it works
+    dvisvgm_is_new_enough = False
+    try:
+        ret = subprocess.run(['dvisvgm', '--version'], stdout=subprocess.PIPE)
+        if b'dvisvgm 3' in ret.stdout:
+            dvisvgm_is_new_enough = True
+    except:
+        pass
+
     # Just winging it here, there doesn't seem to be an easy way to get the
     # actual full path the library was found in -- ctypes/util.py does crazy
     # stuff like invoking gcc (!!) to get the library filename.
     #
     # On Arch /usr/lib64 is a symlink to /usr/lib, so only the former is
     # needed; on Fedora it's two distinct directories and libgs is in the
-    # latter (ugh).
-    prefixes = ['/usr/lib', '/usr/lib64']
-    for prefix in prefixes:
-        libgs_absolute = os.path.join(prefix, libgs)
-        if os.path.exists(libgs_absolute):
-            default_params['libgs'] = libgs_absolute
-            break
-    else:
-        raise RuntimeError('libgs found by linker magic, but is not in {}'.format(' or '.join(prefixes)))
+    # latter (ugh). Elsewhere it might be /usr/lib/x86_64-linux-gnu or just
+    # anything else, so let's just bet that dvisvgm is 3.0+ in most cases and
+    # this gets hit only very rarely.
+    if not dvisvgm_is_new_enough:
+        prefixes = ['/usr/lib', '/usr/lib64']
+        for prefix in prefixes:
+            libgs_absolute = os.path.join(prefix, libgs)
+            if os.path.exists(libgs_absolute):
+                default_params['libgs'] = libgs_absolute
+                break
+        else:
+            raise RuntimeError('libgs found by linker magic, but is not in {}'.format(' or '.join(prefixes)))

 def latex2svg(code, params=default_params, working_directory=None):
     """Convert LaTeX to SVG using dvisvgm.

Thank you!

[juliangilbey]

That's perfect, thank you! I can well imagine how much pain you had with this - I recall facing the same issue myself on a MacOS machine a few years ago.

[mosra]

Yeah, Mac is another thing, also have some workarounds for it there :)

So, just to avoid a misunderstanding -- did the patch work for you?

[juliangilbey]

Yes, the patch worked perfectly on my Debian testing machine.

[mosra]

Awesome! Pushed as 523506668a61646603ed299e1b60b7f77a8ebd77.