GNU Octave interface #54
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks a lot for this nice contribution. I myself am finding it increasingly harder to gain access to a Matlab license to test new versions of proxTV, so an Octave interface is welcomed. However I have been unable to reproduce the installation with success. When running Here is the full error log (though for some weird reason some of the prints are in spanish?) Any idea where this problem could come from? |
|
Hi,
Consider the following fact :
Since you provide many solvers that you compile individually into
objects files (*.o), the mex command line issued gives the dependencies
as "*.o" to avoid listing all of them ; as in `eval(['mex -v -lblas
-llapack -lm ' solver{:} '.cpp "*.o"']);`
The trouble is that some versions of Octave (I think 4.x or less) also
create an intermediate object file for the final mex binary, and do not
delete it automatically. So, once the first solver ("solveTV1_condat" in
the current list) has been compiled, the corresponding object file is
still there, containing a mexFunction() entry. Then, when the next
solver ("solveTV1_condattautstring") is compiled, the former object file
get listed as dependency (through the "*.o"), and the two mexFunction()
entry conflicts.
I am sure that the problem revolves around the above explanation,
because when adding the linker flag "-z muldefs" (basically allowing
multiple definitions; see the documentation of `ld`), the problem
disappears. I submitted a commit correspondingly.
However, the above explanation is certainly incomplete, because:
1) the very first in the list, solveTV1_condat, already gave the
"multiple definition" error; and
2) I actually already took care of the multiple definition problem, with
the line `system(['rm -f ' solver{:} '.o']); so that the faulty object
files should not exist in the system when the next solver is compiled.
Note that if you do force the linkage with -z muldefs but do not remove
the object files after each compilation, the actual problem arise : all
solvers will use the mexFunction() of solveTV1_condat as their entry!
To sum up, the workaround is to add the -z muldefs compilation flag, and
double check that the object files are deleted after each compilation to
avoid actual multiple definitions of the mexFuntion. This does not seem
to be necessary with Octave 5. Note also that I only tested
`solveTVgen`, so you might wanna check that the other solvers compile
correctly.
By the way, if you want to avoid the Spanish output of gcc (which is
most certainly the C compiler called by mex), start Octave with the
`LANG` environment variable set to `C` (or an English locale). On my
shell configuration file, I actually have `alias octave='LANG=C;
/usr/bin/octave-cli' # LANG is for gcc messages`.
Cheers
…On 08/07/2019 20:36, Álvaro Barbero Jiménez wrote:
Thanks a lot for this nice contribution. I myself am finding it increasingly harder to gain access to a Matlab license to test new versions of proxTV, so an Octave interface is welcomed.
However I have been unable to reproduce the installation with success. When running `install_octave.m` I would get a "multiple definitions of mexFunction" for each one of the Matlab .cpp files being compiled. Which is silly, because the error claims about a function with equal name being defined in the same line.
Here is the full error log (though for some weird reason some of the prints are in spanish?)
|
|
Thanks for the LANG tip! However I'm afraid that even after the update the error persists. I have made sure there are no |
|
Hi,
With a closer look, I understand that octave compiles mex files in two
steps : first create an object file, and only then create the executable
file from this object.
Since the second step contains both "*.o" and "solveTV1_condat.o", the
latter appear twice, hence the multiple definitions (and this finally explains the points 1) and 2) that I raised in my previous message).
Moreover, it can be seen from your log files that, with your version of
octave or gcc, the option `-z muldefs` is passed for the first step, but
not for the second step :
g++ -c [...] -fPIC -DOCTAVE -z muldefs -O3 -fopenmp
solveTV1_condat.cpp -o solveTV1_condat.o
g++ -shared -Wl,-Bsymbolic -o solveTV1_condat.mex *.o
solveTV1_condat.o [...]
In this case it is not possible to resort to the "*.o" to specify
dependencies, they must be listed explicitely !
My last commit should do it.
…On 09/07/2019 20:18, Álvaro Barbero Jiménez wrote:
Thanks for the LANG tip!
However I'm afraid that even after the update the error persists. I have made sure there are no `.o` files lying around in the project, but still the log I get now is [...]
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here is a
install_octave.mscript, a slight modification of thesrc/general.hheader and of the documentation inREADME.mdenabling interface with GNU Octave. So that Matlab aficionados can go free and open-source!