The GCC 4.3 patch: --- octave-3.0.0/src/mxarray.h.in.gcc43 2007-10-23 18:32:44.000000000 -0600 +++ octave-3.0.0/src/mxarray.h.in 2008-02-29 11:24:03.000000000 -0700 @@ -46,6 +46,8 @@ #if ! defined (MXARRAY_H) #define MXARRAY_H +#include <cstring> + typedef enum { mxREAL = 0, recently introduced to the octave package causes the octave-forge package to fail to compile: http://koji.fedoraproject.org/koji/taskinfo?taskID=483943 mkoctfile -DHAVE_OCTAVE_30 -v -c odepkg_mexsolver_dopri5.c -o odepkg_mexsolver_dopri5.o gcc -c -DH5_USE_16_API -fPIC -I/usr/include/octave-3.0.0 -I/usr/include/octave-3.0.0/octave -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DHAVE_OCTAVE_30 odepkg_mexsolver_dopri5.c -o odepkg_mexsolver_dopri5.o In file included from /usr/include/octave-3.0.0/octave/mexproto.h:61, from /usr/include/octave-3.0.0/octave/mex.h:77, from odepkg_mexsolver_dopri5.c:39: /usr/include/octave-3.0.0/octave/mxarray.h:49:19: error: cstring: No such file or directory This is because cstring isn't a valid C header file, even though it is valid for C++. Is this patch strictly necessary? It seemed that the previous version octave-3.0.0-3.fc9 compiled OK on GCC 4.3 without that patch. http://koji.fedoraproject.org/koji/buildinfo?buildID=38467
Drat, I guess it was necessary as octave just failed on i386: http://koji.fedoraproject.org/koji/taskinfo?taskID=484004 Odd that it didn't fail for the earlier mass rebuild against GCC 4.3. We obviously need a better solution.
Ah, sorry, didn't realize it got called by non C++ code. Should be able to change to: #include <string.h>
OK, with octave rebuilt with the patch updated as per comment #2, octave-forge has now been successfully rebuilt against it: http://koji.fedoraproject.org/koji/buildinfo?buildID=40252 So closing the bug. Orion or Quentin: has this fix been pushed upstream? If not, can it be?
There is a newer release of octave-forge now available. I was going to try to get it ready for F-9 but have run out of time. It is possible that the new octave-forge release already resolves this problem.