New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hidden failure mode for pdftops when outputting to eps #137

Closed
mpacer opened this Issue Apr 6, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@mpacer

mpacer commented Apr 6, 2016

This took a while to track down, so I thought I'd put it here. I'm new to this package so I can't really submit a PR without spending more time with it & learning how its structured.

tldr; The Matlab2015b version of libfreetype.6.dylib is masking the system one, breaking eps output.

Use otool -L /usr/local/lib/libfreetype.6.dylib to make sure that your local version is 19.0.0 or greater. And then copy that into the MATLAB location: sudo scp /usr/local/lib/libfreetype.6.dylib /Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib. This should fix things for you.

Things to note:

  • This did not raise an error when running -depsc.
  • There is probably a better way to do this by fixing where searching occurs and encouraging the system to continue searching for a system library even when the Matlab one is out of date. That surely is the more robust version. However, that's a much harder fix.

Error & debugging walkthrough:
Thought I'd walk through all the various steps along the way, so that when others search the web for this issue (if it isn't fixed) it has a chance of actually turning up their errors. Also it shows a

So, originally, I got the error saying I didn't have pdftops, and I didn't so I brewed it (I'm on OSX). Or rather I tried brew install xpdf, and was told I needed to first brew tap homebrew/x11, which then gave access to xpdf, making the original brew install xpdf command work.

Ran into issues there with a conflict with poppler, but that was easy enough to solve by unlinking.

However, then I kept getting the error popup inside Matlab. Eventually I got into full debug mode to try to figure it out and needed to set breakpoints many levels deep to find the right system state (i.e., the path_ variable that is passed to check_xpdf_path) after which I ran into the error

check_xpdf_path(path_)

returning "/usr/local/bin/pdftops" -h: Trace/breakpoint trap

Which made no sense to me. Diving into check_xpdf_path I saw that this is the command that was erring: system(sprintf('"%s" -h', path_))

Running that on the matlab command line returned:

dyld: Library not loaded: /usr/local/opt/freetype/lib/libfreetype.6.dylib
  Referenced from: /usr/local/bin/pdftops
  Reason: Incompatible library version: pdftops requires version 19.0.0 or later, but libfreetype.6.dylib provides version 18.0.0
"/usr/local/bin/pdftops" -h: Trace/breakpoint trap

At which point I started writing this issue thinking I'd nearly solved it and wanting to be a good package citizen.

But wait! Little did I know that figuring out what was going on with libreetype was going to be a mess on its own. So I had a lot of difficulty finding any online documentation about libfreetype as one of pdftops's dependencies. And while I was at it… I tried to just brew upgrade freetype I was told it had the newest version…no dice

So the next attempt was to rebuild xquartz to the version that was released in November 2015, presuming that pdftopswas relying on a newer version of the freetype library… I then read through this Automattic/node-canvas#471 set of issues, and didn't have any luck. On both the opt and usr directory libfreetypes when I used otool I was getting

/usr/local/lib/libfreetype.6.dylib:
    /usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 19.0.0, current version 19.3.0)
/opt/X11/lib/libfreetype.6.dylib:
    /opt/X11/lib/libfreetype.6.dylib (compatibility version 19.0.0, current version 19.1.0)

So I was a little befuddled.

And then I looked at that again. Used the sudo find command…and lo and behold, the first return to sudo find / -name libfreetype.6.dylib was:

/Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib

suspicious that there might be some kind of masking going on I tried the otool -L /Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib line, and yep:

/Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib:
    @rpath/libfreetype.6.dylib (compatibility version 18.0.0, current version 18.1.0)

so … it was a matter of copying over the libfreetype.6.dylib file to the Matlab location and it all worked(sudo scp /usr/local/lib/libfreetype.6.dylib /Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib). I figured this approach would be better than fighting with Matlab's path search order.

@altmany

This comment has been minimized.

Owner

altmany commented Apr 6, 2016

@michaelpacer - thanks for taking the trouble and time to write this detailed description. Mighty nice of you. For the benefit of others who might not stumble on this Github issue webpage, can you think of a way to fix export_fig in any way to solve this problem ?

Alternatively, if you let me know exactly which line croaks in export_fig (or one of its child functions), then I could trap this error and at least inform the user that this might be the cause, linking to here.

Let me know please.

@mpacer

This comment has been minimized.

mpacer commented Apr 6, 2016

So it's not that a line croaks so much as it doesn't send back up the full error, making it even harder to debug, and that error was being hidden inside check_xpdf_path(path_) in the pdftops.m file.

I think it was that the system command gives priority to the Matlab search path, and so when it runs system(sprintf('"%s" -h', path_)) where the path_ = "/usr/local/bin/pdftops" it returns

dyld: Library not loaded: /usr/local/opt/freetype/lib/libfreetype.6.dylib
  Referenced from: /usr/local/bin/pdftops
  Reason: Incompatible library version: pdftops requires version 19.0.0 or later, but libfreetype.6.dylib provides version 18.0.0
"/usr/local/bin/pdftops" -h: Trace/breakpoint trap

except it was not even bothering to load from /usr/local/opt/freetype/lib/libfreetype.6.dylib, and then it hides the first parts of that error…so its twice over confusing.

@mpacer

This comment has been minimized.

mpacer commented Apr 6, 2016

It may just be that you need to catch this error, and instead of piping it through to the

while 1
    errMsg = 'Pdftops not found. Please locate the program, or install xpdf-tools from ';
    url = 'http://foolabs.com/xpdf';
    fprintf(2, '%s\n', [errMsg '<a href="matlab:web(''-browser'',''' url ''');">' url '</a>']);
    ⋮

you tell them that even if they have xpdf and therefore pdftops installed, that they may need to copy over their library to the Matlab version so it will find it.

altmany added a commit that referenced this issue May 1, 2016

Added possible error explanation suggested by Michael Pacer (issue #137
…);

improved error presentation;
added sample usage in help section
@altmany

This comment has been minimized.

Owner

altmany commented May 1, 2016

done

@niuqun

This comment has been minimized.

niuqun commented Jun 29, 2018

@mpacer Thank you! It works like a charm.

@YaduNa

This comment has been minimized.

YaduNa commented Nov 29, 2018

Sir, could anyone explain what shall I do if I get error137? I didn't understand what shall I do to avoid it?

@altmany

This comment has been minimized.

Owner

altmany commented Nov 30, 2018

@YaduNa - you need to ensure that the libfreetype.6.dylib file in your pdftops folder is copied over to Matlab's folder, replacing Matlab's version For example:

sudo scp /usr/local/lib/libfreetype.6.dylib /Applications/MATLAB_R2016a.app/bin/maci64/libfreetype.6.dylib

@YaduNa

This comment has been minimized.

YaduNa commented Dec 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment