[petsc-dev] Matlab interface issue

[Vaclav Hapla]

Barry, yes, it does what is needed.

However, I found one more small problem:
make check was throwing
dyld: Library not loaded: @rpath/libicudata.56.dylib
  Referenced from: /Users/vhapla/petsc1/src/snes/examples/tutorials/ex19
  Reason: image not found

I fixed it locally just by adding
-Wl,-rpath,/Applications/MATLAB_R2017b.app/bin/maci64 -Wl,-rpath,/Applications/MATLAB_R2017b.app/extern/lib/maci64
to MATLAB_ENGINE_LIB, PETSC_EXTERNAL_LIB_BASIC and PETSC_WITH_EXTERNAL_LIB
in $PETSC_ARCH/lib/petsc/conf/petscvariables.

Could you please fix configure this way?

Thanks
Vaclav

> 17. 4. 2018 v 23:26, Smith, Barry F. <bsmith at mcs.anl.gov>:
> 
> 
>   Please try the branch barry/feature-matlab-socket/maint  and --with-matlab-socket=0 and let me know if it works.
> 
>   Barry
> 
> 
>> On Apr 17, 2018, at 3:16 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch> wrote:
>> 
>> OK. But definitely it's tricky that you try to inject all PETSc compiler options to the mex wrapper which is by documentation only tested with Xcode and Intel and it's always set up just for one compiler (see mex -setup).
>> 
>> Hence, I would at least vote for config option to turn off this socket mex stuff to bypass potential problems if one doesn't need it. Like --with-matlab-socket=0 or so which would just deactivate the matlabbin target. Or behave like that if --with-matlab-engine=1 and --with-matlab=0 (this currently fails with "Did not find package MATLAB needed by MatlabEngine" which is confusing anyway as it's not a standalone product).
>> 
>> Thanks,
>> Vaclav
>> 
>>> 16. 4. 2018 v 20:30, Smith, Barry F. <bsmith at mcs.anl.gov>:
>>> 
>>> Hmm, I tried on my Mac and had the same problem. But then I upgraded from Matlab 2017A to 2018A and boom the problem went away and it was able to build the socket mex files without a problem.
>>> 
>>> So my conclusion is that we shouldn't change anything in the PETSc makefiles?
>>> 
>>>   Barry
>>> 
>>> 
>>>> On Apr 16, 2018, at 6:41 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch> wrote:
>>>> 
>>>> Hello
>>>> 
>>>> I need to compile PETSc with MATLAB interface on Mac OS.
>>>> 
>>>> First thing is that Mex supports only Xcode or Intel compilers, not GCC. So I compiled PETSc with Xcode, using options
>>>> --with-cc="/usr/bin/xcrun -sdk macosx10.13 clang" --with-matlab --with-matlab-arch=maci64 --with-matlab-engine --with-mpi=0
>>>> 
>>>> But the target "matlabcodes" (in src/sys/classes/viewer/impls/socket/matlab/makefile) was failing with
>>>> Undefined symbols for architecture x86_64:
>>>> "_main", referenced from:
>>>>    implicit entry/start for main executable
>>>> ld: symbol(s) not found for architecture x86_64
>>>> 
>>>> After some investigation I found out the problem lies in specifying environment variables to the mex compiler. Mex has some predefined values of these variables and fails if we override them. According to MATLAB documentation, it should be possible to just append what we need, e.g.
>>>> LDFLAGS='${LDFLAGS} ${PETSC_EXTERNAL_LIB_BASIC}'
>>>> but this apparently does not work as excepted, some predefined options are removed this way. I was debugging that by adding -v to ${MATLAB_MEX} calls in the makefile. It seems the injected LDFLAGS is interpreted _after_ something more is added to LDFLAGS by MEX (stupid).
>>>> 
>>>> What works for me is specifying the options directly do ${MATLAB_MEX}. This is also tricky, though, as ${MATLAB_MEX} does not accept all options, e.g. -Wl,-rpath. So I ended up with replacing
>>>> GCC='${CC}' CC='${PCC}' CFLAGS='${COPTFLAGS} ${CC_FLAGS} ${CCPPFLAGS}' LDFLAGS='${PETSC_EXTERNAL_LIB_BASIC}'
>>>> by
>>>> ${PETSC_CC_INCLUDES} -L${PETSC_DIR}/${PETSC_ARCH}/lib ${PETSC_LIB_BASIC}
>>>> in src/sys/classes/viewer/impls/socket/matlab/makefile. See the attached patch. This at least compiled.
>>>> 
>>>> 
>>>> Do you think this could break anything? Do you have some better idea?
>>>> 
>>>> BTW It would be better if the matlabcodes target could be turned off by configure, if one is interested only in using MATLAB Engine and wants to avoid problems with the mex compiler.
>>>> 
>>>> Thanks,
>>>> Vaclav
>>>> <patch>
>>> 
>> 
>