Tue 22 Sep 2015 09:13:45 PM UTC, comment #15:
Fixed on the stable branch, this will be in the next 4.0 bug fix release:
http://hg.savannah.gnu.org/hgweb/octave/rev/0fdba3fdf40e
|
Thu 11 Jun 2015 02:34:10 PM UTC, comment #14:
For me, on Debian, XTRA_CXXFLAGS="-pthread -fopenmp", and I can see that -fopenmp is not on the link command line for e.g. mpfr_matrix_mul_d.oct, but it successfully builds anyway.
So a viable workaround for now is
to force the linker to correctly link with OpenMP. But this should be fixed in mkoctfile.
|
Wed 10 Jun 2015 07:40:42 PM UTC, comment #13:
The intent is to use OpenMP in interval if it is available. I am fine with using the exact same settings that are used by Octave, which probably is what the user wants.
You are right, passing “-fopenmp” works just as well as passing “-lgomp”.
The difference between Debian and Ubuntu is that mkoctfile uses “-fopenmp -pthread” only in XTRA_CFLAGS on Ubuntu, whereas XTRA_CFLAGS is empty on Debian and these parameters are in CFLAGS.
So, yes, everything would have worked on Ubuntu, if mkoctfile had used XTRA_CFLAGS.
|
Wed 10 Jun 2015 07:28:44 PM UTC, comment #12:
Or... if you build an oct-file that unconditionally needs OpenMP you could add -fopenmp to the mkoctfile command in the package Makefile. This does work, -fopenmp will be added to both the compile and link commands.
Is the intent in interval to use OpenMP if Octave was built with OpenMP but not otherwise? If that's the case then yes, mkoctfile should pass through whatever flags it was built with.
|
Wed 10 Jun 2015 07:26:39 PM UTC, comment #11:
Ok, thanks for taking the time to do that both of you.
This actually looks like a bug in mkoctfile unfortunately.
When mkoctfile builds an oct-file it compiles to a .o file first, and then links the .o to a shared object .oct file. The link stage does not put XTRA_CXXFLAGS on the command line, we need to add this. Automake/libtool do properly add all CXXFLAGS variables to link commands, so oct-files built within Octave's build system are done correctly.
I think this bug might also affect pthreads, e.g. if some oct-file uses some obscure pthreads function that isn't known to Octave it might complain about undefined symbols as well.
Yikes. Thanks for finding this.
|
Wed 10 Jun 2015 07:18:04 PM UTC, comment #10:
Hi Mike,
Thanks for the instructions. I attached the ugly output
For some reason there are 2 versions of gcc in my system. I have the two files
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgomp.spec
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.spec
both with the same contents:
(file #34197)
|
Wed 10 Jun 2015 07:16:13 PM UTC, comment #9:
This is from the Ubuntu virtual machine that I used for reproduction of the bug.
|
Wed 10 Jun 2015 02:45:27 PM UTC, comment #8:
@juanpi can you paste the long ugly output of the following with your version of g++:
This will compile a program called foo, you can delete it when done. The important part of the output is the last section that starts with /usr/lib/gcc/x86_64-linux-gnu/4.9/collect2.
Can you also "locate libgomp.spec" on your system and paste the contents of that file? E.g. on my system it's /usr/lib/gcc/x86_64-linux-gnu/5/libgomp.spec and the file contains
|
Wed 10 Jun 2015 01:37:54 PM UTC, comment #7:
According to that gcc bug report, and according to my experience on Debian, adding -lgomp should not be necessary. The -fopenmp flag should instruct the compiler to add appropriate preprocessor and linker flags, just like -pthread.
The fact that this works fine on Debian but not on Ubuntu is rather telling, can anyone say why this difference? The only results I've found via google have to do with using the Intel compiler on Ubuntu.
|
Wed 10 Jun 2015 05:18:28 AM UTC, comment #6:
So, we have identified the cause. Could somebody with a deeper understanding in mkoctfile please clarify, whether mkoctfile should automatically add “-lgomp” when Octave has been compiled with “--enable-openmp”?
See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24845
|
Tue 09 Jun 2015 09:28:44 PM UTC, comment #5:
The new tar installs fine.
Thanks
|
Tue 09 Jun 2015 09:11:52 PM UTC, comment #4:
I have prepared a patch for the package's Makefile, which fixes the problem in Ubuntu, see changeset http://sourceforge.net/p/octave/interval/ci/481765739e05b0ce2fdd4b69e5e1314385048e83/tree/src/Makefile?diff=a45bb5219e4432e88f9895b72121f22c9d033476
If you are interested in testing the fix before the next release, I have updated the download of the development version (see link in my first comment) with new md5: 5cae972b32cae88f8421fee8adb5fa96
|
Tue 09 Jun 2015 07:55:03 PM UTC, comment #3:
This is probably a duplicate of bug #43948.
I can reproduce on Ubuntu 15.04. After compilation with mkoctfile the error occurs when the oct file is loaded for the first time.
The error does not occur when the parameter “-lgomp” is passed to mkoctfile during compilation.
The error does not occur on Debian 8.1.
Where should this be fixed? In Octave or in the package's Makefile?
|
Tue 09 Jun 2015 11:46:47 AM UTC, comment #2:
I am using Ubuntu 15.04
gcc has omp.h included
The tarbal suffers the same problem
|
Mon 08 Jun 2015 09:52:21 PM UTC, comment #1:
My first guess is that the omp.h does not get included on your system. Please check if you can install the following tarball:
http://octave.ln0.de/interval-0.2.1-dev.tar.gz
md5: 0ccddf38fbb15063781b7d2139ffc531
I have added an include statement for oct-openmp.h, which should correct that cause.
|
Mon 08 Jun 2015 09:31:38 PM UTC, original submission:
With Octave compiled from stable branch 20246:6fe746def1aa
I get
mkoctfile -P XTRA_CFLAGS
gives
-pthread -fopenmp
|