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>