Apparently CPPFLAGS is missing a -I for the newly built compiler's libstdc++ /usr/src/CVS/gcc41/tmp0/./gcc/xgcc -shared-libgcc -B/usr/src/CVS/gcc41/tmp0/./gcc -nostdinc++ -L/usr/src/CVS/gcc41/tmp0/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/src/CVS/gcc41/tmp0/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../../../../libjava/classpath/native/jni/qt-peer -I../../../include -I../../../../../../../libjava/classpath/include -I../../../../../../../libjava/classpath/native/jni/classpath -I../../../../../../../libjava/classpath/native/target/Linux -I../../../../../../../libjava/classpath/native/target/generic -DQT_SHARED -I/usr/lib/qt4/include -I/usr/lib/qt4/include/Qt -g -O2 -D_GNU_SOURCE -MT componentevent.lo -MD -MP -MF .deps/componentevent.Tpo -c ../../../../../../../libjava/classpath/native/jni/qt-peer/componentevent.cpp -fPIC -DPIC -o .libs/componentevent.o In file included from /usr/lib/qt4/include/QtCore/qnamespace.h:27, from /usr/lib/qt4/include/QtCore/qobjectdefs.h:27, from /usr/lib/qt4/include/QtGui/qwindowdefs.h:27, from /usr/lib/qt4/include/Qt/qwidget.h:27, from /usr/lib/qt4/include/Qt/QWidget:1, from ../../../../../../../libjava/classpath/native/jni/qt-peer/componentevent.cpp:38: /usr/lib/qt4/include/QtCore/qglobal.h:30:15: error: new: No such file or directory In file included from /usr/lib/qt4/include/QtCore/qobject.h:31, from /usr/lib/qt4/include/Qt/qwidget.h:28, from /usr/lib/qt4/include/Qt/QWidget:1, from ../../../../../../../libjava/classpath/native/jni/qt-peer/componentevent.cpp:38: /usr/lib/qt4/include/QtCore/qstring.h:43:20: error: string: No such file or directory [...]
This is known and will not be fixed until 4.2.
After hacking the makefiles to get it to build anyway, trying to run an AWT application aborts on startup because gcj renames libqtpeer.so to lib-gnu-java-awt-peer-qt.so, while gnu/java/awt/peer/qt/QtToolkit.java still tries to load libqtpeer. This patch is needed: --- gcc/libjava/classpath/gnu/java/awt/peer/qt/QtToolkit.java.ark 2005-11- 03 09:57:52.000000000 +0100 +++ gcc/libjava/classpath/gnu/java/awt/peer/qt/QtToolkit.java 2005-11-03 09:58 :05.000000000 +0100 @@ -135,7 +135,7 @@ { eventQueue = new EventQueue(); repaintThread = new QtRepaintThread(); - System.loadLibrary("qtpeer"); + System.loadLibrary("-gnu-java-awt-peer-qt"); String theme = null; try
Created attachment 10129 [details] Patch Attaching a fix for both issues in 24403, as well as another compile time problem with the Qt peers. I'll admit any day that what I did to configure.ac/configure is ugly, dirty, and evil(tm), but it's preferrable over simply not working at all
First off, qt-peers are experimental, even in classpath (cp). The componentevent.cpp part is covered already in the next cp release. Which we will import soon. The build process we have to adjust. We can not modify the cp machinery this way. Cp is standalone and we have to pass our (gcc/libgcj) specific flags 'down' to cp. To do this we need some time. We may need to modify cp configury but in a way cp accepts this. We may have to enter one level up and propagate the libstdc++ flags with absolute PATHS. Which means modifying the toplevel. So for the moment, means the next few moons, we have to stay with a non satisfying situation. Hopefully we have a solution in 4.2 which we can backport to 4.1.x We're working on this.
Instead of the patch in comment #2, I think we want to simply make this loadLibrary conditional on 'Configuration.INIT_LOAD_LIBRARY'. See GtkToolkit.java for an example; FWIW this change is already in Classpath CVS. I haven't looked at the configure/Makefile additions yet. I'm sure that whatever happens here will be plenty ugly :-)
(In reply to comment #0) > Apparently CPPFLAGS is missing a -I for the newly built compiler's libstdc++ I borrowed a snip from libjava/Makefile.am section for xlib, which also needs c++/libstdc++, then (since I am no autoconf/automake expert) made an awful hack with CTRL+Z during compile-time and manually added the correct flags to AM_CXXFLAGS in libjava/classpath/native/jni/qt-peer/Makefile with variables substituted , and the qt-peers built with no problem and worked. The snip from xlib is here: lib_gnu_awt_xlib_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ -I../libstdc++-v3/include \ -I../libstdc++-v3/include/$(target_noncanonical) \ -I$(srcdir)/../libstdc++-v3/libsupc++ so my Makefile has: AM_CXXFLAGS = -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui \ -I/home/tmp/mybuild/gcc-trunk/i686-pc-linux-gnu/libstdc++-v3/include \ -I/home/tmp/mybuild/gcc-trunk/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu \ -I/usr/src/gcc-trunk/libstdc++-v3/libsupc++
Created attachment 11803 [details] updated build hack for mainline.
Created attachment 12045 [details] Updated fix, works for multilib arches too This new fix is even more ugly than the old one because I couldn't find a sane way to tell the 64-bit and the 32-bit build apart on a multilib arch -- so I had to resort to the insane way. But it works perfectly, and should at the very least tell someone who knows the gcc build system better than I do what needs to be done.
Created attachment 12081 [details] Updated to work with today's trunk
Created attachment 12086 [details] Updated fix for current trunk+multilib
ping... > This is known and will not be fixed until 4.2. Now that 4.2 is released and it still doesn't work, can we get this working in 4.3?
Do you have a copyright assignment? If so I will review the proposed patch. I think the bigger problem is that the Qt peers are not really maintained. ISTR that they still have some pretty serious bugs, though that is just hearsay, as I have not tried them myself.
yes, assignment is in place, and yes, the peers are somewhat buggy. But I think that's in part because nobody (at least in the gcj community) is testing/fixing them because they don't build without trickery.
(In reply to comment #11) > ping... > > This is known and will not be fixed until 4.2. > Now that 4.2 is released and it still doesn't work, can we get this working in > 4.3? Thats the spirit guys! So many threads have a reply that says: "it's broken, don't do it" - I say enable it, and lets fix it! I'm compiling "gcc version 4.3.0 20070716" and as far as "_building_" goes, it works - not at the _testing_ part yet. Make sure you alter file "gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/jni/gtk-peer/Makefile" to use "moc-qt4" and not "moc" (if your "moc" is for Qt3). gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr/test --enable-objc-gc --disable-multilib --with-gxx-include-dir=/usr/test/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib,qt,x --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-libgcj-debug --enable-plugin --enable-tool-wrappers --enable-portable-native-sync --enable-examples --with-dwarf2 --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-tune=athlon-xp --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree
After my "moc-qt4" fix to the Makefile I have test results to prove it built: Results for 4.3.0 20070716 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00721.html
ping... This missed 4.3 again, it should probably get in now before 4.4 enters freeze mode... Re the moc -> moc-qt4 change suggested in comment #14: This should be detected by the configure script, moc-qt4 is a nonstandard way some distributions use to tell moc 3.x apart from moc 4.x, other candidates for the correct moc include "moc4" and simply launching moc from a different path (/usr/lib/qt4/bin/moc) if the default moc is from 3.x
(In reply to comment #16) > ping... > This missed 4.3 again, it should probably get in now before 4.4 enters freeze > mode... How about 4.5 ? > Re the moc -> moc-qt4 change suggested in comment #14: This should be detected > by the configure script, moc-qt4 is a nonstandard way some distributions use to > tell moc 3.x apart from moc 4.x, other candidates for the correct moc include > "moc4" and simply launching moc from a different path (/usr/lib/qt4/bin/moc) if > the default moc is from 3.x > "a nonstandard way some distributions..." I was using GNU/Linux with GNU's gcc - nonstandard or "The Standard". There are no Docs for having both QT3 _and_ QT4 but it is permissible. Read these Docs here: http://doc.trolltech.com/4.4/moc.html -- use "-v" to check that the "moc" you found (on path, and check the "usual directories" too) is for QT4 and not QT3. On OpenSolaris 2008.11 Qt4 is using this to check the version: # /usr/local/Trolltech/Qt-4.4.3/bin/moc -v Qt Meta Object Compiler version 59 (Qt 4.4.3) Rob
With my fix I can configure with "--enable-java-awt=gtk,xlib,qt,x", see: Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC) testsuite on i386-pc-solaris2.11 http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html Rob
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.