Mon, 08/20/2007 - 23:26
Forums:
Can't compile QtOcc 0.9 on Linux, Debian, gcc/g++ 4.1.2, Qt 4.2.1:
from src/QoccApplication.cpp:26:
/usr/include/qt4/QtCore/qdatastream.h:31:2: error: #error qdatastream.h must be included before any header file that defines Status
Any suggestions ?
Tue, 08/21/2007 - 04:38
Actually 0.9 has never properly been validated on Linux. However, apparently the addition of the following defines can work wonders.
-DHAVE_IOSTREAM
-DHAVE_FSTREAM
-DMAVE_LIMITS_H
Take a look at the discussion on http://www.opencascade.org/org/forum/thread_10815/
Cheers
Pete
Tue, 08/21/2007 - 14:42
On my openSUSE 10.2 + OCC 6.2 + Qt 4.2.1
i have such error message:
sergei@kism-nep:~/qtocc/QtOCC-0.9> make
make -f Makefile.Release all
make[1]: Entering directory `/home/sergei/qtocc/QtOCC-0.9'
g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DCSFDB -DQOCC_STATIC -DLIN -DLININTEL -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include/QtOpenGL -I/usr/include/QtOpenGL -I/usr/include -I. -Iinc -I/opt/OpenCASCADE6.2.0/ros/inc -I/usr/X11R6/include -Irelease -I. -o release/main.o main.cpp
inc/QoccViewerContext.h:32: error: ISO C++ forbids declaration of ‘Handle_V3d_Viewer’ with no type
inc/QoccViewerContext.h:32: error: expected ‘;’ before ‘&’ token
inc/QoccViewerContext.h:33: error: ISO C++ forbids declaration of ‘Handle_AIS_InteractiveContext’ with no type
inc/QoccViewerContext.h:33: error: expected ‘;’ before ‘&’ token
...
In QoccViewerContext.h:
#include
#include "Qocc.h"
but where are no any openCASCADE includes in Qocc.h
So, we must include QoccInternal.h in Qocc.h :(
Tue, 08/21/2007 - 14:42
On my openSUSE 10.2 + OCC 6.2 + Qt 4.2.1
i have such error message:
sergei@kism-nep:~/qtocc/QtOCC-0.9> make
make -f Makefile.Release all
make[1]: Entering directory `/home/sergei/qtocc/QtOCC-0.9'
g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DCSFDB -DQOCC_STATIC -DLIN -DLININTEL -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include/QtOpenGL -I/usr/include/QtOpenGL -I/usr/include -I. -Iinc -I/opt/OpenCASCADE6.2.0/ros/inc -I/usr/X11R6/include -Irelease -I. -o release/main.o main.cpp
inc/QoccViewerContext.h:32: error: ISO C++ forbids declaration of ‘Handle_V3d_Viewer’ with no type
inc/QoccViewerContext.h:32: error: expected ‘;’ before ‘&’ token
inc/QoccViewerContext.h:33: error: ISO C++ forbids declaration of ‘Handle_AIS_InteractiveContext’ with no type
inc/QoccViewerContext.h:33: error: expected ‘;’ before ‘&’ token
...
In QoccViewerContext.h:
#include
#include "Qocc.h"
but where are no any openCASCADE includes in Qocc.h
So, we must include QoccInternal.h in Qocc.h :(
Tue, 08/21/2007 - 14:46
sorry:( i have some troubles with my internet connection:(
Tue, 08/21/2007 - 14:43
On my openSUSE 10.2 + OCC 6.2 + Qt 4.2.1
i have such error message:
sergei@kism-nep:~/qtocc/QtOCC-0.9> make
make -f Makefile.Release all
make[1]: Entering directory `/home/sergei/qtocc/QtOCC-0.9'
g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DCSFDB -DQOCC_STATIC -DLIN -DLININTEL -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include/QtOpenGL -I/usr/include/QtOpenGL -I/usr/include -I. -Iinc -I/opt/OpenCASCADE6.2.0/ros/inc -I/usr/X11R6/include -Irelease -I. -o release/main.o main.cpp
inc/QoccViewerContext.h:32: error: ISO C++ forbids declaration of ‘Handle_V3d_Viewer’ with no type
inc/QoccViewerContext.h:32: error: expected ‘;’ before ‘&’ token
inc/QoccViewerContext.h:33: error: ISO C++ forbids declaration of ‘Handle_AIS_InteractiveContext’ with no type
inc/QoccViewerContext.h:33: error: expected ‘;’ before ‘&’ token
...
In QoccViewerContext.h:
#include
#include "Qocc.h"
but where are no any openCASCADE includes in Qocc.h
So, we must include QoccInternal.h in Qocc.h :(
Tue, 08/21/2007 - 18:49
Sergei,
It looks like you've fallen foul of a concept I have been developing in my major trunk code, for which the 0.9 viewer version is a cut down version. What I've been trying to do is start encapsulating some of the code into shared libaries (or DLLs in my case). The idea I had was that the Qocc.. classes should sit in their own library, which is linked to the OCC libs but the "main" application should be capable of being compiled without needing to be explicitly linked to OCC. Unfortunately whilst this works fine on VS2005, gcc is throwing up some unforeseen issues. There are two possibilities. You could pick the 0.7 version which uses the old class and which was proven on Linux. However if you want to use 0.9, the way I'd suggest going is to use a few forward class declarations rather then including thw whole of QoccInternal.h which was being designed as the start of a private implementation model (or Pimpl pattern).
For instance, try chaning QoccViewerContext.h to read
.
.
// Forward declarations
class Handle_V3d_Viewer;
class Handle_AIS_InteractiveContext;
class QOCC_DECLSPEC QoccViewerContext : public QObject
{
.
.
instead of loading the whole QoccInternal.h include. Hope this helps
Pete
Wed, 08/22/2007 - 12:03
Thank you!
I just use some classes of your QtOcc 0.6 in my own project,
so i don't need to use QtOcc as shared library...
Code from QtOcc 0.6 works great on:
openSUSE 10.2 + GCC + Qt + Boost.Build v2
and VC2005 + Qt + Boost.Build v2
P.S.: I really need QtOcc for my project,
so i want to join QtOcc project. How can i do it?
P.P.S.: Sorry for my english:(
Thu, 08/23/2007 - 03:59
QtOCC (or Qocc now perhaps) isn't so much a project at the moment, but a hobby. I'd originally intended it to evolve into a mesh generator framework, something like Salome perhaps, that could use say Netgen, Gmsh, Tetgen. The idea was to build a toolset that could command "plugins" for other developers to exploit. Along the way I found a number of, how shall I put it, "undocumented features" in OCC so I started making my own changes to the core. However I have become aware that there seems to be a well documented need for an open source CAD/Solid Modeller program for Linux. The "Kreative3d" team over at KDE seem to have spent 18 months and have finally decided that the name needs changing - not much elase. They have also decided NOT to use OCC as its license is apparently not compatible with Debian (not something that the Gmsh team worried about when they integrated OCC).
So the point is that I'm not sure what direction makes the most sense. I'd like to achieve both goals, i.e. have a damn good geometry editor for a mesh generator. But this takes time, and if I turn it a project with collabators I'd need to start designing, defining requirements and so on ( and that's the day job ). If there is sufficient interest however, I would consider say a Sourceforge hosted project.
At the moment the best thing I can ask anyone for is to get the 0.9 viewer running on Linux (and on win32 with NVidia). The current application shell (and it still looks better than it works) looks like http://myweb.tiscali.co.uk/dolbey/QtOpenCascade/images/QtOCC5.PNG - this is based on a number of features within the evolved 0.9 version, such as the class renaming to Qt standards, and also consistent use of lower case filenames.
If there is interest in developing a community project, respond back here - I'm monitorng this thread.
Pete
Fri, 08/24/2007 - 01:47
I solved it. It runs now on Linux, had to modify the init procedure.
Fri, 08/24/2007 - 11:24
Adrian,
Could you post back your changes on this thread, or email to "peter at dolbey dot freeserve dot co dot uk".
Cheers,
Pete
Mon, 08/27/2007 - 08:06
Adrian,
It is very interesting to see changes!
Tue, 08/28/2007 - 22:01
Here is my initOcc function:
void GLWidget::initializeOCC()
{
// Init Occ
Aspect_RenderingContext rc = 0;
myViewer = myContext->CurrentViewer();
myView = myViewer->CreateView();
int windowHandle = (int) winId();
short lo = (short) windowHandle;
short hi = (short) ( windowHandle >> 16 );
rc = (Aspect_RenderingContext) glXGetCurrentContext(); // Untested!
myWindow = new Xw_Window( Handle(Graphic3d_GraphicDevice)::DownCast( myContext->CurrentViewer()->Device() ),
(int) hi, (int) lo, Xw_WQ_SAMEQUALITY, Quantity_NOC_BLACK );
Handle(Xw_Window) hWnd = new Xw_Window(Handle(Graphic3d_GraphicDevice)::DownCast(myContext->CurrentViewer()->Device()),(int) hi,(int) lo,Xw_WQ_SAMEQUALITY);
myView->SetWindow( hWnd );
if ( !hWnd->IsMapped() )
hWnd->Map();
myView->SetBackgroundColor(Quantity_NOC_BLACK);
myView->MustBeResized();
#ifdef OCC_PATCHED
myView->TriedronDisplay( Aspect_TOTP_LEFT_LOWER, Quantity_NOC_WHITE, 0.1, V3d_ZBUFFER );
#else
myView->TriedronDisplay( Aspect_TOTP_LEFT_LOWER, Quantity_NOC_WHITE, 0.1, V3d_WIREFRAME );
#endif
myViewer->SetDefaultLights();
myViewer->SetLightOn();
}
Fri, 08/31/2007 - 17:45
Hi Dolbey,
I've tried your 0.6 QtOcc and I have a couple of things that don't work...
1) For compilation I had to add the -fpermissive flag for GCC 4.1.2, if not, it throws:
***
QtOCCViewWidget.cpp:102: error: ambiguous default type conversion from ‘Handle_V3d_View’
QtOCCViewWidget.cpp:102: error: candidate conversions include ‘Handle_Standard_Transient::operator Standard_Transient*()’ and ‘Handle_Standard_Transient::operator const Standard_Transient*() const’
QtOCCViewWidget.cpp:102: error: type ‘class Handle_V3d_View’ argument given to ‘delete’, expected pointer
***
2) If compiled with this flag "-fpermissive" (which shouldn't be a problem). It doesn't run and exits with these errors:
Compiled as Release:
***
terminate called after throwing an instance of 'Aspect_GraphicDeviceDefinitionError'
Aborted
***
Compiled as Debug:
Segmentation fault
Thank you,
.alvaro.
Fri, 08/31/2007 - 17:48
Hi Dolbey,
I've tried your 0.6 QtOcc and I have a couple of things that don't work...
1) For compilation I had to add the -fpermissive flag for GCC 4.1.2, if not, it throws:
***
QtOCCViewWidget.cpp:102: error: ambiguous default type conversion from ‘Handle_V3d_View’
QtOCCViewWidget.cpp:102: error: candidate conversions include ‘Handle_Standard_Transient::operator Standard_Transient*()’ and ‘Handle_Standard_Transient::operator const Standard_Transient*() const’
QtOCCViewWidget.cpp:102: error: type ‘class Handle_V3d_View’ argument given to ‘delete’, expected pointer
***
2) If compiled with this flag "-fpermissive" (which shouldn't be a problem). It doesn't run and exits with these errors:
Compiled as Release:
***
terminate called after throwing an instance of 'Aspect_GraphicDeviceDefinitionError'
Aborted
***
Compiled as Debug:
Segmentation fault
Thank you,
.alvaro.
Fri, 08/31/2007 - 17:49
Hi Dolbey,
I've tried your 0.6 QtOcc and I have a couple of things that don't work...
1) For compilation I had to add the -fpermissive flag for GCC 4.1.2, if not, it throws:
***
QtOCCViewWidget.cpp:102: error: ambiguous default type conversion from ‘Handle_V3d_View’
QtOCCViewWidget.cpp:102: error: candidate conversions include ‘Handle_Standard_Transient::operator Standard_Transient*()’ and ‘Handle_Standard_Transient::operator const Standard_Transient*() const’
QtOCCViewWidget.cpp:102: error: type ‘class Handle_V3d_View’ argument given to ‘delete’, expected pointer
***
2) If compiled with this flag "-fpermissive" (which shouldn't be a problem). It doesn't run and exits with these errors:
Compiled as Release:
***
terminate called after throwing an instance of 'Aspect_GraphicDeviceDefinitionError'
Aborted
***
Compiled as Debug:
Segmentation fault
Thank you,
.alvaro.
Thu, 09/13/2007 - 21:59
Hello again,
I think this is a little flawed in that you can't forward declare and use the declared type as a concrete type. You have him forward declaring a type that you have a concrete instance of further down. Only if its a pointer.
Looks like VS is allowing you outside the standard in this way.
Fri, 08/31/2007 - 17:52
Sorry! I had problems with internet connection...
Sat, 09/01/2007 - 11:23
That error is typical of an incorrect environment setting for CSF_GrahpicShr not pointing to the (lib)TKOpenGL.
Pete
Sun, 09/02/2007 - 22:38
hi again!
Thanks for your response. However I'm now trying this again at home and (I don't know why) it doesn't compile even with the -fpermissive flag set.
Could you tell me exactly which kind of cast (if that is the solution) should be made to tell the compiler the correct from these ones (as it seems that it can't figure it out):
'Handle_Standard_Transient::operator Standard_Transient*()'
"or"
'Handle_Standard_Transient::operator const Standard_Transient*() const'
Just to check if it compiles the rest, I removed that code of line. I supposed that as it is in the destructor it shouldn't be a problem if the widget is never destroyed. Then it compiles. But when I run it, returns the segmentation problem. The environment variable you said is pointing to TKOpengl library correctly (I double-checked it).
I tried again with 0.7 and 0.6, same problems ( 0.7 shows somehting else about rc that I think I could solve). I imagine these are all problems related to the gcc version 4+.
Here, at home I'm using a gentoo, but at work I'm using fedora core 6.
I would really appreciate if you help me with this.
Thank you very much,
Best regards,
.alvaro.
Mon, 09/03/2007 - 04:05
Just comment out the offending line 102 (// delete myView;), I'm not sure its needed.
In fact the whole QtOCC demo thing is in serious need of a re-write both for Windows and Linux - I will need Linux collaborators as I haven't got any environments.
One problem is that the Windows version can cause an exception to be thrown when the window is mapped on the myView->SetWindow( ... ); line. Unfortunately I have not been able to reproduce this error. However Pawel Dobrowolski has been doing some debugging for me. I think the problem is related to the video cards, and it my ATI Radeon thats "wrong".
After a bit of digging about through the call stack and a bit of web research, I’m now pretty sure I know what the problem is.
When you derive a class from QGLWidget, Qt4 uses a platform independent wrapper around OpenGL. On win32, this involves running through a section of code that describes the pixel format for the OpenGL rendering context. This involves calling the win32 API SetPixelFormat.
A rendering context is also set up though the SetWindow method in the Visual3d_View, which calls SetPixelFormat again. According to the Microsoft documentation, you can only call SetPixelFormat once for any window. Unfortunately QtOCC calls this twice, even though I thought I had added code to re-use the Qt4 context.
Now my suspicion is that those nice guys at ATI who wrote the device drivers for the Radeon card sort of ignored this part of the specification, and allowed SetPixelFormat to be called multiple times on the same window, however that nasty nVidia developers followed the specification exactly and ensured that the call cannot be made twice.
This is why the earlier 0.3 version that inherited from just QWidget works well on win32 for most users, but this later version doesn’t.
The “gotcha” is the reverse problem occurred in the Linux world (which of course doesn’t have the same SetPixelFormat API call). Here QGLWidget worked and QWidget didn’t. Now this is probably because I didn't add the extra code in the original Qt3 code that sets up the visuals for x11. This also would need upgrading for Qt4.
For a fix I have a number of possibilities
Fix the OpenCascade routine that is supposed to re-use exiting rendering contexts (requires user to patch OCC)
Change the Qt4 code (not very good plan for a similar reason with patching Qt4)
Change the inheritance model to use QWidget – Find collaborators for Linux solution (preferred option)
Inherit from QGLWidget on Linux/X11, and QWidget on win32 (short term fix – ugly hack, but should work)
So the solution roadmap is likely to be 4, as these options are known to work separately, then find help with 3. I’ll try to build an option 4 solution during the next week.
Anyone who can help debug/test this is welcome to post back to this thread.
Pete
Sun, 09/02/2007 - 22:49
I forgot to say that I'm always under a 64 bits linux, if that's useful
Mon, 09/03/2007 - 20:13
Same message on my linux box with QT > 4.2.x. Anyone here has QtOcc-0.9 up and running with linux?
Mon, 09/03/2007 - 21:01
Markus,
Which message? Several have been posted on this thread.
Pete
Mon, 09/03/2007 - 21:13
By the way,
On other threads, posters have found that adding "-ffriend-injection" compile option fixes some of the non-conforming OCC headers, as well as the "-fpermissive".
I'm starting to feel that I need to build a virtual Linux box - any recommendations for the OS.
Pete
Tue, 09/04/2007 - 00:20
Yes, I started that thread and found that solution. However this guy is much nicer :-) He posted patches 3 days ago:
http://www.cae.wisc.edu/~kraftche/OCC/patches.html
This is the gdb output. Something tells me it *might* have to do with that delete...
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /home/humano/Desktop/QtOCC-0.6/QtOpenCascade
[Thread debugging using libthread_db enabled]
[New Thread 47308112531440 (LWP 25131)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47308112531440 (LWP 25131)]
0x00002b06bb109c35 in Handle_Standard_Transient::EndScope (this=0x2b06bb365a70)
at ../../../src/Standard/Handle_Standard_Transient.cxx:41
41 entity->count--;
Current language: auto; currently c++
Tue, 09/04/2007 - 00:26
A recommendation for the Linux distribution:
If you don't want to waste your time (as I do with my little gentoo), use Ubuntu. In addition, Debian flavored distributions have in my opinion much more support from community. But I don't want to start here a discussion about that! :-)
You will get latest libraries and 64 bits system easily.
About the widget, I've been taking a look at how Ogre3d deals with Qt (as it is a 3d render engine) and found this:
http://www.ogre3d.org/wiki/index.php/QtOgre
Of course, I can see that you fought quite a lot more to get yous up and running, but maybe there is some clue there as it has a similar problem about owning the 3d window.
Tue, 09/04/2007 - 00:35
I'm new to both Qt and Open Cascade, but I can try help testing / debugging linux version. I really need a solid widget to work with Open Cascade under linux.
Thanks for your dedication!
Wed, 09/05/2007 - 08:53
Hi Dolbey!
About Linux distribution:
I think that openSuSE 10.2 is a good choice
i use this distribution for developing
(OCC 6.2 + Qt 4.2 + Some parts of QtOCC + Boost.Build v2)
Other good distributions for development:
Debian 4 Etch
Kubuntu 7.04
PCLinuxOS 2007
CentOS 5 (based on Red Hat Enterprise Linux 5)
Wed, 09/05/2007 - 11:04
Sergei,
Actually, I've just built an OpenSUSE 10.2 VM for testing - mainly because SUSE is my work's target Data Centre platform, but I don't see many people here with a need for Oracle/J2EE and so on!
Pete
Thu, 09/06/2007 - 09:14
It is impossible to test QtOCC on all distributions. So there is a sense to use only enterprise distributions, as manufacturers of CAD/CAM/CAE packages do. For example NX5 requires SLED9 SP2. You can use SLED, SLES or CentOS 5 for free ;)
Thu, 09/06/2007 - 10:12
Hi Pete,
thanks for building a VM!
If you need webspace / traffic to share this VM let me know, I could provide this.
Markus
Wed, 09/12/2007 - 17:39
Hello,
I've been trying to solve the compilation issues on linux for the last version of QtOCC-0.9
I made some changes needed to build and it does fine now, even without that nasty issue of deleting the Handle_V3d_View in the destructor.
However, the same segmentation fault rises.
Are you still working on this?
I'm trying to solve it myself, following the QGLWidget vs QWidget possibility that you proposed.
Thanks!
Wed, 09/12/2007 - 23:43
Alvaro,
Yes for my sins I keep working on it. Last night I sent a 0.9a to Pawel to see if we can fix the SetPixelFormat issue on non-ATI graphics cards (er, like nVidia). This uses inheritance from QWidget, and as ideally I'd like to keep the same basic object heirarchy model for both Win32 and Linux.
I know that both Qt3 examples and the Salome widgets derive from QWidget. There is a chunk of code in the sample widget constructor that looks like:-
#ifndef WNT
XSynchronize( x11Display(),true ); // it is possible to use QApplication::syncX();
XVisualInfo* pVisualInfo;
if ( x11Display() )
{
/* Initialization with the default VisualID */
Visual *v = DefaultVisual( x11Display(), DefaultScreen( x11Display() ) );
int visualID = XVisualIDFromVisual( v );
/* Here we use the settings from Optimizer_ViewInfo::TxglCreateWindow() */
int visualAttr[] = { GLX_RGBA, GLX_DEPTH_SIZE, 1, GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1,
GLX_BLUE_SIZE, 1, GLX_DOUBLEBUFFER, None };
pVisualInfo = ::glXChooseVisual( x11Display(), DefaultScreen( x11Display() ), visualAttr );
if ( isVisible() )
hide();
XSetWindowAttributes a;
Window p = RootWindow( x11Display(), DefaultScreen( x11Display() ) );
a.colormap = XCreateColormap( x11Display(), RootWindow( x11Display(), pVisualInfo->screen ),
pVisualInfo->visual, AllocNone );
a.background_pixel = backgroundColor().pixel();
a.border_pixel = black.pixel();
if ( parentWidget() )
p = parentWidget()->winId();
Window w = XCreateWindow( x11Display(), p, x(), y(), width(), height(),
0, pVisualInfo->depth, InputOutput, pVisualInfo->visual,
CWBackPixel | CWBorderPixel | CWColormap, &a );
Window *cmw;
Window *cmwret;
int count;
if ( XGetWMColormapWindows( x11Display(), topLevelWidget()->winId(), &cmwret, &count ) )
{
cmw = new Window[count+1];
memcpy( (char *)cmw, (char *)cmwret, sizeof(Window)*count );
XFree( (char *)cmwret );
int i;
for ( i = 0; i < count; i++ )
{
if ( cmw[i] == winId() ) /* replace old window */
{
cmw[i] = w;
break;
}
}
if ( i >= count ) /* append new window */
cmw[count++] = w;
}
else
{
count = 1;
cmw = new Window[count];
cmw[0] = w;
}
/* Creating new window (with good VisualID) for this widget */
create(w);
XSetWMColormapWindows( x11Display(), topLevelWidget()->winId(), cmw, count );
delete [] cmw;
if ( isVisible() )
show();
if ( pVisualInfo )
XFree( (char *)pVisualInfo );
XFlush( x11Display() );
}
#endif
However, for Qt4 this needs to be translated to use the QX11Info class model, which isn't even delivered in the Win32 Qt4 version. That's why I'm having to build a OpenSUSE virtual machine under VirtualPC, to compile the Linux version of QtOCC. Unfortunately I don't have enough kit to build multiple environments any other way.
If anyone can volunteer to help do this on Linux that would be great as I haven't got OCC running on the Linux VM yet - that's tonights job.
When Pawel gives me the nod, I will make a win32 only version available for wider testing (Jeez, this is sounding more like day job with every post).
Pete
Thu, 09/13/2007 - 03:12
OpenCascade on SUSE working now... Qt4 next... then QtOCC...
Pete
Thu, 09/13/2007 - 14:55
Well, using the old "puts()" method I have this new information:
This line:
defaultdevice = new Graphic3d_GraphicDevice( getenv("DISPLAY") );
...is throwing the Segmentation fault. That happens without creating any other stuff related to OpenCascade in the QApplication:
*******************
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
static Handle(Graphic3d_GraphicDevice) defaultdevice;
defaultdevice = new Graphic3d_GraphicDevice( getenv("DISPLAY") );
return app.exec();
}
************************
And the gdb output (after 10 mins. thinking), like before:
************************
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912633144384 (LWP 4957)]
0x00002aaaabf95aed in Handle_Standard_Transient::EndScope (this=0x60aac8)
at ../../../src/Standard/Handle_Standard_Transient.cxx:41
41 entity->count--;
Current language: auto; currently c++
************************
I hope this helps.
Thu, 09/13/2007 - 17:04
I forgot to say something I've found that might save you some time.
When you use Xlib.h or Xw_Extension.h, these MUST be included allways at the end of the includes.
Is written in the qcorevent.h that you might get a weird compilation issue because there is a redefinition on the same scope of something that QT uses. For instance, the first message describes what it looks like this problem. For that reason these shouldn't be included in OccInternal.h but explicit where needed but at the end, in my opinion. I tried it and it solves that problem.
Thu, 09/13/2007 - 14:18
Pete,
What I've been doing is just that: trying to port the qt3 project that comes with OpenCascade to qt4.
As I said before, I'm not expert in Qt or OpenCascade (new to both). So probably I'm missing key parts. However, I did try changing that functions which seem quite straightforward and indeed simplifies the code. I'm under 64 bits, but OpenCascade seems to work fine with the Draw Test Harness. But I still haven't been able to compile any example (there are only qt3 and java examples). The problem with the qt4 version I'm trying to build is that I can't debug because everything fills twice my RAM so it becomes exceedingly slow.
Well, I keep trying this eventhough I've been lost since the beginning. :-)
Don't hesitate if you want to ask for some tests in any of my native linux platforms.
Thanks,
.alvaro.
Thu, 09/13/2007 - 20:40
Alvaro,
Nice work so far. I got Qt4 working this morning (before work, well breakfast actually) after an overnight compile, and the qt3 OpenCascade sample is working surprisingly well as well. Hopefully I should be able to start work on the QtOCC Linux port tonight. If you've got any code mods you can send them to me at "peter at dolbey dot freeserve dot co dot uk" and they will be gratefully received.
Cheers
Pete
Fri, 09/14/2007 - 10:59
I will try to test new version of QtOCC 0.9a during the weekend.
I think it is very good job that you do here.
Sorry for delays. 24 hours during the day are not enough for me.
Pawel
Fri, 09/14/2007 - 23:16
A quick note:
Could we use the function XCreateWindow(...). That seems to work well for the Draw Test Harness. If that is just able to build a new window, there should be something to get the screen or just a region...
this is all Xlib library, of course. That makes me think that the fact that some distributions (like mine) are starting to use XCB -the replacement for xlib- might be a source for problems.
these are just thoughts :-). I'll read more about xcb compatibility with xlib.
You can take a look at src/Draw/Draw_Window.cxx
Sat, 09/15/2007 - 01:34
I managed to run QtOCC 0.9a successfully for the first time on Nvidia Card (GeForce 2).
Peter has done very good job.
We are another step closer to QT Occ template for both environments Windows and Linux.
Peter will make this version available for everyone after few corrections.
Greetings
Paul.
Mon, 09/17/2007 - 11:07
Well I had a go at porting QtOCC to OpenSUSE over the week-end. I built a system that would let me develop on Windows, upload to Linux via FileZilla, and compile the same code immediately. Most of the porting involved re-organising the order of included files. The only main gotcha was that I need to creat a link between libtcl8.4.so and libtcl.so.0 as below (as root):
cd /usr/lib
ln -s libtcl8.4.so libtcl.so.0
Using an unmodified OCC 6.2 install, and a Qt 4.3.1 open source install, gcc 4.1.2, I can present the following image as proof that my code compiles and runs under both Windows and OpenSUSE. http://myweb.tiscali.co.uk/dolbey/QtOpenCascade/QtOCCPort.PNG
The code used is here:- http://myweb.tiscali.co.uk/dolbey/QtOpenCascade/QtOCC-0.10.zip
Note that I inherited from QWidget, but did not need any of the X11 code shown previuosly - and that surprised me as well!
See if it works for you.
Mon, 09/17/2007 - 12:18
I forgot to say that I did need to alter the path in my .profile for the Qt4 folders - I also put all the OCC env variables in the .profile as well. I'm at work not, but I can show the details tonight.
Pete
p.s. I can well imagine that this is still not the "final cut". Unfortunately, as before with Windows, I can't now reproduce any failures (yet).
Mon, 09/17/2007 - 13:00
Pete,
Thank you very much for your work!
I still have what seems a small issue related to linking:
*******************************
/opt/OpenCASCADE6.2.0/ros/Linux/lib/libTKService.so: undefined reference to `XmuCreateColormap'
/opt/OpenCASCADE6.2.0/ros/Linux/lib/libTKService.so: undefined reference to `XmuPrintDefaultErrorMessage'
*******************************
Probably this involves the recompilation of OpenCascade with XMU support (I might have removed it). As I said before, I'm under 64bits and I had to recompile everything. That already took me hours!
Did you use any new method from this library (TKService)? Because this wasn't rised before, and I'm starting to think of possible connections with the segmentation fault.
Again, thanks for your effort!
Mon, 09/17/2007 - 17:50
Ok it compiles now, after activating XMU support in OpenCascade.
However, I have bad news from my computer: I get the same segmentation fault I got before. Exactly the same error I submitted above when executed in gdb.
At this point I have no clue of where to start, specially if it works properly for you. What I said before about Xlib and XCB is just too generic to be to problem, and if it is so, it should affect most new distributions.
Thanks Pete,
.alvaro.
Mon, 09/17/2007 - 21:31
Alvaro,
You need to remember that I' still a Linux newbie. Every thing I have done so far has been with vanilla OCC/Qt4 installed on 32-bit and running under KDE - and I think I've been lucky so far. Here's some basic questions.
1. Does the standard qt3 demo compile and run properly?
2. What is your current environment setting for DISPLAY (e.g. env | grep DISPLAY)?
Pete
Tue, 09/18/2007 - 02:40
GOT IT!
I knew it! You have to add the _OCC64 define and the -m64 flag to the QtOCC project. That was the reason it was working for you and not for me. The precompiled binaries are 32 bits. So it was affecting the Standard_Transient as it is dealing with 64 bits pointers inside for sure, the origin of the problem.
So now, we should only add some 64 bits detection. I use the cmake build system I know how to do it there, I don't know how it would be in the qmake project.
Thank you for all, thanks Pete for your effort. I'm ready to collaborate with any further issue concerning QtOcc under linux 64 bits.
Don't hesitate to ask me any question about my quest dealing with QtOCC under linux 64 bits.:-)
Tue, 09/18/2007 - 02:44
My proof:
http://www.alvarocastro.es/external/Qt4-OpenCascade-linux-64bits.jpg
:-)
Tue, 09/18/2007 - 09:55
Alvaro,
Fantastic news - hope fully now we are now fully cross-platform. What do we do next? I had thought about looking at the "sketcher" code and adding that functionality as an enhancement to the "demo".
Pete
Tue, 09/18/2007 - 10:49
Alvaro,
I forgot to add that you should be able to target compiler directives to specific platforms. In the mkspecs folder in your Qt install should be a "linux-g++-64" make spec definition in qmake.conf.
You should be able to add block into the qtoccharness.pro file that looks like
linux-g++-64: {
DEFINES += ....
QMAKE_CXXFLAGS += ....
}
This is from memory, but it is documented in Qt Assistant. You should be able to put the specific configuration in this block. Unfortunately, I can't prove it works. If you can fix, send me back the .pro file - you know how to find me.
Pete
p.s. A big thanks to all those who have actively helped on this little project, Alvaro, Sergei, Pawel and of course Marc Britten from the early days. A small project yes, yet one that shows the benefits of open source through world-wide collaboration.