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. <[email protected]>: > > > 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 <[email protected]> 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. <[email protected]>: >>> >>> 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 <[email protected]> >>>> 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> >>> >> >
