App-defaults and not found in compiled versions



I have installed the compiled version (v4303) of CellProfiler on an amd64 linux machine and when it starts it gives the following message:

Warning: latest verion of matlab app-defaults file not found.
Contact your system administrator to have this file installed.

A similar message was seen in my compiled version of CellProfiler and CPCluster on this machine plus an additional message:

Warning: Unable to load Java Runtime Environment: cannot open shared object file: No such file or directory.
Warning: Disabling Java support.

Despite the warning, CPCluster still runs the pipeline but my version of CellProfiler hangs on pipeline execution (? may or may not be related to this warning).

The Matlab website ( … n=1-2R5223) suggest to use the following on a 64bit machine:

Matlab suggestion:
There is an error in the documentation for MATLAB Compiler 4.4 (R2006a) with regards to the value of the LD_LIBRARY_PATH environment variable on 64-bit Linux platforms.

On a development machine, the documentation should read:

setenv LD_LIBRARY_PATH $MATLABROOT/sys/os/glnxa64: $MATLABROOT/bin/glnxa64: $MATLABROOT/extern/lib/glnxa64: $MATLABROOT/sys/java/jre/glnxa64/jre1.5.0/lib/amd64/native_threads: $MATLABROOT/sys/java/jre/glnxa64/jre1.5.0/lib/amd64/server: $MATLABROOT/sys/java/jre/glnxa64/jre1.5.0/lib/amd64 setenv XAPPLRESDIR $MATLABROOT/X11/app-defaults

As an example, the contents of my CellProfiler.command is:

BASEDIR=dirname $0
export mcr_path=$BASEDIR/MCR/v74
export LD_LIBRARY_PATH="$mcr_path/runtime/glnxa64:$mcr_path/sys/os/glnxa64:$mcr_path/bin/glnxa64:$mcr_path/sys/java/jre/glnxa64/jre1.5.0/lib/amd64/native_threads:$mcr_path/sys/java/jre/glnxa64/jre1.5.0/lib/amd64/server:$mcr_path/sys/java/jre/glnxa64/jre1.5.0/lib/amd64:$mcr_path/Modules/“
export XAPPLRESDIR=”$mcr_path/x11/app-defaults"
#export DISPLAY=":0.0"
echo $1 $2
$BASEDIR/CPCluster $1 $2;

The Matlab LD_LIBRARY_PATH paths are not in the system paths and are only added when Matlab is excuted so it should not conflict with the compiled versions which loads its own version when executed.

Look forward to any suggestions you may have.



Sorry for the delay. Are you still having this issue, or has it been resolved? Please let us know.