Error compiling GNU Octave

Hello:

Although GNU Octave 10.3 is in latest ports (in quarterly te version is 10.2), I would like to compile the software by myself. In Linux the compilation runs without problems, but in FreeBSD 15 I obtain an error. The ./configure script runs without warning, but in the compilation I obtain
CXX liboctave/util/libutil_la-quit.lo
liboctave/util/quit.cc:39:27: error: conflicting declaration 'std::atomic<long int> octave_interrupt_state'
39 | std::atomic<sig_atomic_t> octave_interrupt_state{0};
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from liboctave/util/quit.cc:37:
liboctave/util/quit.h:227:38: note: previous declaration as 'std::atomic<int> octave_interrupt_state'
227 | extern OCTAVE_API std::atomic<int> octave_interrupt_state;
| ^~~~~~~~~~~~~~~~~~~~~~
liboctave/util/quit.cc: In function 'void octave_handle_signal()':
liboctave/util/quit.cc:117:58: error: cannot bind non-const lvalue reference of type 'std::__atomic_base<int>::__int_type&' {aka 'int&'} to a value of type 'sig_atomic_t' {aka 'long int'}
117 | ! octave_interrupt_state.compare_exchange_weak (curr_interrupt_state, -1))
| ^~~~~~~~~~~~~~~~~~~~
In file included from /usr/local/lib/gcc14/include/c++/atomic:50,
from liboctave/util/quit.cc:30:
/usr/local/lib/gcc14/include/c++/bits/atomic_base.h:552:41: note: initializing argument 1 of 'bool std::__atomic_base<_IntTp>::compare_exchange_weak(__int_type&, __int_type, std::memory_order) [with _ITp = int; __int_type = int; std::memory_order = std::memory_order]'
552 | compare_exchange_weak(__int_type& __i1, __int_type __i2,
| ~~~~~~~~~~~~^~~~
gmake[2]: *** [Makefile:25929: liboctave/util/libutil_la-quit.lo] Error 1
Anyone knows what can be the reason for this error?
 
The best thing to do is study the port.
Does it use patches in /files ? Study them.

If using the same version in ports there should be no problem but if downloaded version of Octave is newer there may be additional work involved.

So study /usr/ports/distfiles/ version of Octave. Then look at patches. See if code source patch line numbers match up to files.
 
When I was learning u-boot I would compile the port and "cut and paste" the entire command line string.
It needs a large "Toolchain" setup to compile it.

Perhaps you should compile the port and look at the toolchains required and what happens with a successful build.
It's all in the ports Makefile but can be hard to interpret.
 
How is the OP getting the source tree?
Pulling from upstream site or using a ports tree?

If from the upstream site, then definitely need to look at the port.
 
Thank you for all your answers. My problem is that I installes FreeBSD in VirtualBox and I can't plot with Octave. When I try to plot a figure I obtain the error
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
the program freezes and becomes unusable.
Then, I tried to compile from the sources downloaded from www.octave.org. The configure script was fine and then I obtained the error of my first post. I checked the files in https://codeberg.org/FreeBSD/freebs...d5d3a24e8a18b3d1c478a6253a7/math/octave/files and I made the changes in the files, but now I obtain some linking errors due to GraphicsMagick++ and Suitesparte, that I have installed.
 
SirDice is right.. I see those message spammed all over my Xconsole/F1 on some CAD programs.
Instruction missing on my older cpu. But it still works.

Perhaps the crash is related. Perhaps it is not? Why would the port work but your build does not. That is why I recommend looking at a port build.
See what it uses. Replicate it from the command prompt.
 
...but now I obtain some linking errors due to GraphicsMagick++ and Suitesparte, that I have installed.
This problem is almost certainly caused by a missing /usr/local/lib in the linker's library search path. See the -L option in the man page.

Just another one of those things you gotta do to compile things in Freebsd. Tell us again, why can't you just use the port?

Edit: Are you going to try and debug your freeze? I would try running on real hardware first. The problem, if any, is likely in the virtualized graphics stack. It may not actually be a problem, it may be that it's drawing so slowly that it appears to be frozen.

Then again, I forget most people have just a single laptop to work on nowadays. I guess I'm the only one who always has 2-3 spare machines to mess with at any given time.
 
I guess I'm the only one who always has 2-3 spare machines to mess with at any given time.
I moved to a stack of Gen7/8/11 NUC's for testing Poudriere. Real hardware and to install FreeBSD takes under 10 minutes.
Reinstall system to make sure its reproducible. Rinse and repeat until process established.

I was thinking the OP should consider a clean env before attempting to build from scratch. After compiling port and taking copious notes. Making use of package-depends ect ect.
 
Back
Top