3

Q: how do I share a pdf-tools installation between computers?

I use pdf-tools on two difference machines, and sync my .emacs.d between them via Dropbox.

I have installed pdf-tools through the package manager. pdf-info-epdfinfo-program points to the executable epdfinfo, which pdf-tools builds when installing. That's apparently a problem.

Formerly, I ran one machine on MacOS and another on Linux (Fedora), and neither one could use the other's epdfinfo executable. I now run one machine with Fedora and another with Ubuntu, and, surprisingly, I have the same problem despite both being Linux: the Fedora machine can't use the Ubuntu machine's epdfinfo and vice-versa. The error message suggests that it cannot one of the poppler libraries:

pdf-info-check-epdfinfo: Error running ‘/home/dan/Dropbox/.emacs.d/packages/pdf-tools-20170417.150/epdfinfo’: /home/dan/Dropbox/.emacs.d/packages/pdf-tools-20170417.150/epdfinfo: error while loading shared libraries: libpoppler.so.64: cannot open shared object file: No such file or directory

What I have done in the past is:

1) install pdf-tools on one machine and save a copy of its executable (say, as epdfinfo-alt),

2) install pdf-tools on the other machine,

3) copy epdfinfo-alt into the pdf-tools directory,

4) put a conditional statement in my init file like:

;; pseudocode
(when (eq machine machine-alt)
  (setq pdf-info-epdfinfo-program
        "some-directory/epdfinfo-alt"))

Surely there is a better way to share a pdf-tools install between machines that are not running the same operating system or flavor of Linux. How do I do it without going to all this fiddly trouble?

Dan
  • 32,980
  • 7
  • 102
  • 169
  • What do you mean by 'neither one could use the other's epdfinfo'? What error did Emacs report when you tried? If you can solve the problem by saving the file in another location, it suggests there may be an issue with permissions or the executable bit - the name and location shouldn't matter on their own? – Tyler Nov 28 '17 at 14:35
  • @Tyler: I've posted the error message. It can't find one of the shared libraries with which the executable is built (it relies on poppler). – Dan Nov 28 '17 at 14:43
  • does your workaround, steps 1-4, require you compile epdfinfo on both machines, or have you been able to compile epdfinfo on one machine and use it on the other after renaming it? I suspect the libpoppler library has a different name or location on each system, a problem you shouldn't be able to fix just by renaming the executable – Tyler Nov 28 '17 at 15:51
  • @Tyler: I wasn't clear enough. I install pdf-tools on each machine, which, in turn, compiles a different epdfinfo on each machine. However, I don't have to deal with the poppler issues once I have the two compiled executables, because I have the janky conditional statement in the init file that uses the executable made by the current machine. – Dan Nov 28 '17 at 15:53
  • ok, that makes sense. In that case, it seems clear that you can't cross-compile epdfinfo to work on both systems, at least not without some non-trivial tinkering. So the problem comes down to Dropbox syncing the executable, when you'd rather it be ignored so you can have a different file on each machine? I could offer suggestions, but they end up being similarly janky to what you're already doing. – Tyler Nov 28 '17 at 16:16
  • @Tyler: thanks for the thoughts. I think the problem is that the package creates a system-specific executable, rather than relying on an extra executable that's already on the system (eg, by packaging epdfinfo as something one installs on the system, separate from pdf-tools). I've noticed a roughly analogous problem with emms, which is not purely elisp (it now includes a program written in C called emms-print-metadata, which is frustrating to deal with). – Dan Nov 28 '17 at 16:20
  • 1
    this is a long-standing feature request https://github.com/politza/pdf-tools/issues/154 – Tyler Nov 28 '17 at 20:32
  • @Tyler : I think that means the answer is “there isn’t a non-fiddly way to do it.” If you post that link to the issue request and give a brief explanation for the benefit of future readers, I’ll accept it. – Dan Nov 28 '17 at 21:10
  • You should set-up the pdf-info-epdfinfo-program variable conditionally according to the sytem that's currently running before loading pdf-tools. Then the package should pick-up that path, verify that the exe is ok or compile it otherwise. – politza Nov 29 '17 at 18:13

1 Answers1

2

pdf-tools requires a separate executable, epdfinfo, in order to function. This executable is distributed as source code within the pdf-tools package. As such, it gets compiled whenever you install or update the pdf-tools package.

This is convenient, as it provides one-step installation of the pdf-tools package, which includes code for installing the dependencies for epdfinfo automatically.

This is also a hassle, as it means epdfinfo gets compiled with every update of pdf-tools, whether or not it has actually changed. And, as you've discovered, it makes it non-trivial to sync your emacs config across different computers.

Syncing should work between any two computers on which the dependencies of epdfinfo have the same names and locations. That should mean computers with the same distro version (i.e., two machines that both run Debian Wheezy, or that both run Ubuntu 14.4), or that at least have the same file system hierarchy and library structure (i.e., Ubuntu 17 and the version of Debian that it was built from). But systems with different file system hierarchies or library packaging (Fedora vs Ubuntu) or OS (Mac vs Linux) will not produce cross-compatible binaries, so syncing won't work.

This issue has been raised with the pdf-tools developer, and he's receptive to splitting epdfinfo into a separate installation, eventually.

Tyler
  • 22,234
  • 1
  • 54
  • 94