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>
>>
>
