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

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: https://unix.stackexchange.com/questions/171262/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.