[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew Janke
Subject: Re: [Octave compilation on macOS 11.2.2 with MacPorts 2.6.4 and GCC 10.2.0]
Date: Tue, 9 Mar 2021 07:19:36 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.8.0

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]