On Fri, 5 Nov 2010, Miguel de Benito Delgado wrote:
I read at qtcentre (http://www.qtcentre.org/archive/index.php/t-7223.html) that this problem was due
to duplicate symbol definitions in the preprocessor and then it was related to the order of inclusion
of header files.
Thanks! After reading this, I wrote the following patch which fixes the
compilation problem in Linux.
diff -r -U1 TeXmacs-1.0.7.7-src.orig/src/System/Files/image_files.cpp TeXmacs-1.0.7.7-src/src/System/Files/image_files.cpp
--- TeXmacs-1.0.7.7-src.orig/src/System/Files/image_files.cpp 2010-10-23 02:38:02.000000000 +0700
+++ TeXmacs-1.0.7.7-src/src/System/Files/image_files.cpp 2010-11-08 19:43:16.000000000 +0600
@@ -25,2 +25,5 @@
#ifdef QTTEXMACS
+#ifdef CursorShape
+#undef CursorShape
+#endif
#include "Qt/qt_utilities.hpp"
It seems that the problem is well-known; there is a "standard" solution,
namely, /usr/include/fixx11.h (so, instead of these 3 lines, one might
just insert 1: #include <fixx11.h>). But this file belongs to kdelibs, and
not every Linux user has it installed. So, my patch is more limited but
more portable (and it solves the immediate problem).
Hmm. It seems that during the last year nobody has ever compiled TeXmacs
with --enable-qt on any kind of Linux. Otherwise, this problem would be
encountered by somebody:
X11/X.h:
#define CursorShape 0
QtCore/qnamespace.h:
enum CursorShape { ... }
which, of course, becomes
enum 0 { ... }
Not a very encouraging thought...
Andrey