libcairo undefined symbol: FT_Get_Var_Design_Coordinates error when calling R from compiled MATLAB application on Centos7

Question

I'm posting this question to document the solution to a problem which had me stuck for several weeks for which no answer was found on StackExchange or discussion boards. (Answer forthcoming)

I'm trying to run a compiled matlab program (MATLAB 2017a) compiled using the application compiler toolbox (Matlab compiler 6.4) on a Centos7 operating system. The tricky part is that my Matlab program uses the "system" command to call R and knit an rmarkdown document.

To get standalone matlab programs to run on linux operating systems it is necessary to set LD_LIBRARY_PATH like thus:

export LD_LIBRARY_PATH={$LD_LIBRARY_PATH}:/usr/local/MATLAB/MATLAB_Runtimev92/v92/runtime/glnxa64:/usr/local/MATLAB/MATLAB_Runtimev92/v92/bin/glnxa64:/usr/local/MATLAB/MATLAB_Runtimev92/v92/sys/os/glnxa64:/usr/local/MATLAB/MATLAB_Runtimev92/v92/sys/opengl/lib/glnxa64

The problem was, this broke R in the following way:

In grDevices::png(f) :
  unable to load shared object '/usr/lib64/R/library/grDevices/libs//cairo.so':
  /lib64/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates

Testing the R code independently I found it ran fine when run with sudo privileges. This didn't work because the MATLAB program wouldn't work when run with sudo privileges.

Turns out, sudo privileges clear LD_LIBRARY_PATH: LD_LIBRARY_PATH always blank after sudo

One workaround I found was to change my system call in MATLAB to call with sudo but its a sloppy fix since it requires the user to type their sudo password halfway through the program run. So I'm looking for a better fix.

Answer 1

So with some research I found that the issue with libcairo was really an issue with freetype. This question- https://stackoverflow.com/questions/60782074/r-issue-unable-to-load-shared-object-cairo-so-on-linux-centos-7 -suggests that multiple freetype libraries can be the problem, however doing rpm freetype:

rpm -q freetype
freetype-2.8-14.el7_9.1.x86_64
freetype-2.8-14.el7_9.1.i686

Found there were not duplicate freetype libraries.

Turns out LD_LIBRARY_PATH is searched before the os libraries: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Sure enough running find:

sudo find / -type f -iname 'libfreetype.so.*'
/usr/lib/libfreetype.so.6.14.0
/usr/lib64/libfreetype.so.6.14.0
/usr/local/bin/glnxa64/libfreetype.so.6.11.1
/usr/local/MATLAB/MATLAB_Runtimev92/v92/bin/glnxa64/libfreetype.so.6.11.1
/usr/local/MATLAB/R2017a/bin/glnxa64/libfreetype.so.6.11.1

Revealed what rpm wouldn't - MATLAB had it's own freetype libraries! Which LD_LIBRARY_PATH made override the os freetype library (hence why R worked when sudoed).

The most consistent fix is two parts:

1. Make sure LD_LIBRARY_PATH is only set as part of the original call to the standalone MATLAB program, which can be done with the run_MyProgram.sh file created when compiled.
2. In your MATLAB code make sure that all "system" calls clear LD_LIBRARY_PATH before running. ie:

function [status,cmdout]=systemAlt(cmd)
    if isunix()
        [status,cmdout]=system(['export LD_LIBRARY_PATH="";',cmd]);
    else
        [status,cmdout]=system(cmd);
    end
end

Oddly I also needed to download new fonts to get it work properly:

yum install xorg-x11-font*

So there - if anyone is stuck like me I hope that helps you out.

Answer 2

Funny enough, the same issue was with QNX SDK 7.1 Momentics IDE. Removal of libfreetype.so.6 found under ${HOME}/qnxmomenticside helped with the issue, as libcairo.so.2 linked with proper system libfreetype