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.ha...@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. <bsm...@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.ha...@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> >> >