Thu, 03/26/2009 - 03:48
I'm trying to develop my first OCC application.
Been working almost exclusively in Java the last 10 years, so this is all a little bit strange.
As my first "test" app, I've rearranged some of the packaging of the Java samples, along the lines of http://www.opencascade.org/org/forum/thread_9295/ (also http://www.opencascade.org/org/forum/thread_10022/).
So I need to rebuild TkNativePaint.dll, which I've changed to reflect my new packaging (yes, I'm on Windows, Eclipse 3.4 CDT w/MinGW, OCC 6.3.0). However I, like a number of people, have had trouble getting the link dependencies resolved.
A forum search (http://www.opencascade.org/org/forum/thread_10548/) suggested to just include everything, which I did (all of ros/win32/lib + jawt.lib), but I still had 27 undefines.
Further searching suggested that I should remove compilation optimization.
(http://www.opencascade.org/org/forum/thread_11865/)
Interestingly, this reduced the number of undefines to 18!
All look to be OCC related.
Focusing on a single undefined:
V3d_Viewer::CreateView()
Used "Dependency Walker" (http://www.dependencywalker.com/), and this symbol appears in TKV3d.dll, so I'm perplexed, since TKV3d.lib is included in the build.
Perhaps another compiler or linker option?
Defines used: WNT,_MBCS,_AFXDLL,__MINGW32__,WIN32,_WINDOWS
Link flags: -Wl,--add-stdcall-alias
I'm sure there's some kind person out there that can give me a quick tip on how to resolve this.
Alternatively, perhaps a guide describing "OCC on Windows" development.
(BTW - I've already read every forum thread containing "unresolved" or "link error")
Many thanks.
Here is the linker command line:
g++ -LC:\OpenCASCADE6.3.0\ros\win32\lib -LC:\OpenCASCADE6.3.0\3rdparty\win32\jvm\lib -Wl,--add-stdcall-alias -shared -olibTkNativePaint.dll CASCADEView3d.o CASCADEView2d.o -lBinLPlugin -lBinPlugin -lBinTObjPlugin -lBinXCAFPlugin -lFWOSPlugin -lmscmd -lPTKernel -lStdLPlugin -lStdPlugin -lTKAdvTools -lTKBin -lTKBinL -lTKBinTObj -lTKBinXCAF -lTKBO -lTKBool -lTKBRep -lTKCAF -lTKCDF -lTKCDLFront -lTKCPPClient -lTKCPPExt -lTKCPPIntExt -lTKCPPJini -lTKCSFDBSchema -lTKDCAF -lTKDraw -lTKernel -lTKFeat -lTKFillet -lTKG2d -lTKG3d -lTKGeomAlgo -lTKGeomBase -lTKHLR -lTKIDLFront -lTKIGES -lTKjcas -lTKLCAF -lTKMath -lTKMesh -lTKMeshVS -lTKNIS -lTKOffset -lTKOpenGl -lTKPCAF -lTKPLCAF -lTKPrim -lTKPShape -lTKService -lTKShapeSchema -lTKShHealing -lTKStdLSchema -lTKStdSchema -lTKSTEP -lTKSTEP209 -lTKSTEPAttr -lTKSTEPBase -lTKSTL -lTKTCPPExt -lTKTObj -lTKTObjDRAW -lTKTopAlgo -lTKTopTest -lTKV2d -lTKV3d -lTKViewerTest -lTKVRML -lTKWOK -lTKWOKTcl -lTKXCAF -lTKXCAFSchema -lTKXDEDRAW -lTKXDEIGES -lTKXDESTEP -lTKXMesh -lTKXml -lTKXmlL -lTKXmlTObj -lTKXmlXCAF -lTKXSBase -lTKXSDRAW -lwokcmd -lwokdeliverysteps -lwokdfltsteps -lwokobjssteps -lwokorbixsteps -lwoksteps -lwoktoolscmd -lwokutilscmd -lXCAFPlugin -lXmlLPlugin -lXmlPlugin -lXmlTObjPlugin -lXmlXCAFPlugin -ljawt
Thu, 03/26/2009 - 09:59
There is a little problem in what you are doing: you are using MinGW with MSVC compiled libraries. Although MinGW supports MSVC libraries to some extent, it seems the support is not complete. It could probably be solved with some special switches, or by altering the order of the libraries. I already tried once to use MinGW with OCC's MSVC libraries, but I also ran into the same problem as you. I found a post describing my problem, but no solution (which is quite common).
If you succeed in your task, do not forget to post what you did. I am quite interested in seeing it working like that.
Yet another option would be to fully recompile OCC with MinGW, but it is also very tricky to do so.
Good luck.
Thu, 03/26/2009 - 19:51
That's an interesting explaination. Thanks!
I used MinGW because it was the simplist and easiest. Alternatively, I could use cygwin. Or would I still have the same problem?
Thu, 03/26/2009 - 22:15
The GMSH team built a MinGW patched version of OCC 6.2 available here
http://www.geuz.org/gmsh/beta/occ/
Pete
Fri, 03/27/2009 - 00:53
Thanks again.
The patched version linked above is labeled to indicate support for cygwin also. So that appears to settle my question about that.
But this seems to show that if someone wants to develop to OCC on Windows, as it is updated over time (6.3.0 etc.), we should be using the (non-open source) MS Visual Studio. Too bad...
Fri, 03/27/2009 - 09:51
Well, you could probably use the Express edition of MSVC in that case.
Now, about Cygwin, it also uses the same compiler as MinGW: GCC. The difference is that Cygwin offers a Unix like set of tools along with it, plus the compiler is "tuned" to work with that environment. If you do not need all of that, just stick with MinGW. What would be really nice is to be able to convert those MSVC project files to something else that can use MinGW. I already tried with Code::Blocks' project importer, but those project files use a quite evil configuration that the importer ignores: compiler options per file. I have already discussed the issue in the Code::Blocks' forums, but nothing has been done about it... yet. I will try bumping that post, or even checking myself if I can do something about it.
If I get something working, I will post it here (at least the Code::Blocks project files to compile it).
Fri, 03/27/2009 - 20:42
Success!
After spending many days working the Eclipse/gcc route, it only took about a half and hour with Visual Studio, despite not working with C++ for almost 10 years.
Now if I can just get it to run...
(you won't be hearing from me unless I'm unsuccessful after several days of effort)
Sat, 03/28/2009 - 01:13
Initially would complile/link using Visual Studio, but wouldn't run.
Java could find the library okay, but couldn't reference the "paint" method (which had been changed to reflect my new Java packaging).
Adding 'extern "C"' fixed this.
'extern "C"' is not in the original file, which seemed to work just fine with the original build, so there must be some compile/link option. But after all the time I spent, I'm not picky...
Mon, 03/30/2009 - 10:01
I am glad to hear you finally got it working.
I bumped the post about the importer, but I also realized a small issue: the syntax used in the project files would have to be converted to GCC's. In other words, getting working project files to compile OpenCASCADE with MinGW would take a long time. Not just that, there is also a lack of motivation to work on that.
I wonder if MSYS could be used to compile OCC. Has anyone tried that?
Fri, 04/17/2009 - 14:46
I would like to comment that I am currently building OCC 6.3.0 with all patches I could find using Code::Blocks (which uses MinGW). It's a long process because I have to edit many options by hand that are not imported from the MSVC project files. So far the biggest issue was that TKGeomAlgo did not want to link because the command line was too long for Windows to handle. I had to work around it until the command line was short enough to be issued. Other than that, the process is going almost smoothly. Chances are I will only compile up to the Visualization workspace.
I wouldn't mind sharing the binaries, Code::Blocks workspaces and modified files if anyone is interested (and if it works as expected, also). It would take me some time to arrange it, though.