Re: [Octave compilation on macOS 11.2.2 with MacPorts 2.6.4 and GCC 10.2.0]

[Andrew Janke]

On 3/9/21 5:44 AM, Maxim Abalenkov wrote:
> Hello Andrew,
>
> Thank you very much for your help! I do need to compile Octave from 
> source code, because in the future I will need to refactor some of the 
> Octave source code, especially the “mxArray” variable, that conflicts 
> with the MATLAB definition of “mxArray". You may see my yesterday’s 
> email regarding that issue.

Oh yeah, I saw that! Not to be a downer, but you're screwed, dude. This 
is an _ambitious_ project.

> I found this post on StackOverflow and I’m 
> currently trying to configure and compile Octave adding the 
> “—with-libiconv-prefix=/opt/local/“ option. Unfortunately, that failed 
> and the /opt/local/include and /opt/local/lib directories are not picked 
> up or picked up too late. Now I have added the /opt/local into 
> CFLAGS=-I/opt/local/include, LDFLAGS=-L/opt/local/lib and LIBS=-liconv. 
> I have also dubbed these flags in CXXFLAGS and FCFLAGS.

Maybe this is a pkgconfig issue? Do all your packages have pkgconfig 
definitions?

> I didn’t deal with the BLAS/LAPACK errors yet. I was hoping the 
> configure script will pick up Apple’s Accelerate framework. But it seems 
> this is not the case. If you have any advice on how to ensure Octave 
> uses Accelerate I would be grateful. In the worst case I will install 
> the OpenBLAS.

In my past experience, the Octave configure script _will_ pick up 
Apple's Accelerate framework just fine. Octave.app shipped against Apple 
Accelerate for ~years before we explicitly switched it to use OpenBLAS, 
if I recall correctly. I'm wondering if maybe you are picking it up and 
there are some functions it doesn't implement, at least in this 
macOS/SDK version?

> I’m a regular user of MacPorts and I was fine with the version 6.1.0 
> until recently, when I figured out I have a conflict with MATLAB’s 
> “mxArray” definition. That’s why I may need to refactor Octave’s 
> codebase, renaming “mxArray” into “mtrxArray” for example. It is an 
> intrusive change. But so far I don’t see an elegant solution.

Sorry dude, I think you are seriously SOL here. "mxArray" is an 
undocumented, not-for-external-use, internal data structure from 
Matlab's perspective, and I think from Octave's perspective too. (There 
may even be patent and copyright issues here.) You are deep in There Be 
Dragons Here territory here. God only knows what'll happen if you try 
mixing Matlab and Octave's definitions of it in a single executable.

> Thank you and have a good day ahead!

You too! I wish you well in your endeavor, however pessimistic about it 
I may seem.

Cheers,
Andrew