Main place for discussions about U++ cross platform development framework.
Added OCE (OpenCascade Community Edition) 3d solid modeling kernel -- UPDATED to 0.10 version
PLEASE SEE LAST POST FOR LATEST INSTRUCTIONS ! Hi, finally I could add this package, which I'm using in my UppCad. It was a long run because the library source tree is totally Upp-unfriendly AND because it's so big that I couldn't drop into bazaar. BEWARE, NEEDS AN UPDATED IDE TO BUILD !!! (nighty build from 18/01/2011) So, here instructions : 1 - RTFR (Read The Fine Readme) !!! 2 - If you're in a hurry, please read point 1. 3 - If you're *really* in hurry, keep in mind that the Bazaar package DON'T have the library sources inside (around 30 MB were just too big...), just the .upp files and some other neede ones, so, you MUST fetch the library source tree by yourself. So, as contained in the infamous README file, as an option : From inside OCE folder...... If using GIT (preferred method): git clone git://github.com/tpaviot/oce.git If not using git, fetch files from here : https://github.com/tpaviot/oce/zipball/master Unpack them inside OCE folder AND BE SURE that resulting folder name is 'oce'. You'll end with OCE folder containing following: ApplicationFramework Draw FoundationClasses InterfaceGraphic_WNT.hxx ModelingAlgorithms ModelingData oce <<-- THIS IS OCE source tree OCE.h README-REALLY.txt Visualization From now, you can open OCETest package and run it... if all is ok, you'll see a small demo with a 3d bottle on it. BE PATIENT, OpenCascade is totally Blitz-unfriendly, and it's around 30 MB of source code. On Linux it takes around 20-25 minutes to build on my machine, on WINE it takes more than one our, don't know on a real machine. You can zoom (mouse wheel) pan (middle mouse button) and rotate (ctrl+shift + mouse middle drag). Tested on windows an Ubuntu Linux 11.10; if you've some BSD handy, please test it and/or apply needed patches. Please report here any bugs you find ! LAST NOTE : GIT is preferred because the OCE project is very active on these days and we're fixing tons of issues on it, so with git you can stay updated easly. Ciao Max
Re: Added OCE (OpenCascade Community Edition) 3d solid modeling kernel
Hi Koldo I'll be happy if you can test it. It was quite difficult having it packaged without touching at source tree... and I'm not completely happy about, but that's the only way by now. On next days I'll adapt my UppCad to the new package and push a couple of windows+linux test versions somewhere. Ciao Max
Hello Massimo It is great to have good engineering tools in U++. And OpenCascade is perhaps one of the most advanced available to open source. So IMHO having it in U++ is very good news .
Ide now can build the sample without patches. Just update to a nigthy build (today 18/01/2011) Please test ! Max
Sorry for bumping a rather old topic. Just a small heads up. It appears that the new version (0.10.*) of OpenCascade does not compile properly with the bazaar project - one has to use the older 0.9* code.
Hi, I just updated the bazaar OCE package to latest OCE build, and so is the demo app. Now there's just a *BIG* single library named OCE. As before,you need to fetch the OCE sources with git from OCE website; see the readme file. As a note, the OCE package still has a couple of bugs that prevents building on last ubuntu GCC; I pushed the needed patches in a private branch named miciomax/fix-ubuntu-build, so upon fetching the git code, you need to switch to that private branch to build it. Resumed instructions : 1: cd into OCE bazaar folder 2: git clone git://github.com/tpaviot/oce.git oce 3: cd into 'oce' folder 4: git checkout miciomax/fix-ubuntu-build From now you can try to build demo code. By now, tested JUST on Linux; you may miss some dependencies, in my case it was TCL devel libraries and limxmu, but your mileage may vary... jut look at error codes, if any, and google for dependencies. I'll test it on windows (and make needed changes...) on next days. Ciao Max p.s.: the build takes LOOONG... if you don't have a fast pc with very fast HDD. On my quad core i7 with 512 GB ssd it takes some 3-5 minutes; on former machine it could take 2 ours.... p.p.s: I warmly suggest to build with USEMALLOC flag... maybe the OCC allocators are fixed now, but they were quite broken one year ago....
Re: Added OCE (OpenCascade Community Edition) 3d solid modeling kernel -- UPDATED to 0.10 version
Ciao Massimo, Good to hear that the new version is almost ready! Here's a small report on my attempt to compile OCETest under Windows, using the latest OCE code and version 5575 of u++: It's not working yet, but it's almost there. Compiling with gcc 4.7.0 I get the following: Quote: C:\upp\bazaar\OCE\oce\src\OSD\OSD_Thread.cxx: In function 'DWORD WNTthread_func(LPVOID)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_Thread.cxx:145:11: error: 'intptr_t' was not declared in this scope C:\upp\bazaar\OCE\oce\src\OSD\OSD_Thread.cxx:145:20: error: expected ';' before 'ret' C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx: In function 'BOOL MoveDirectory(LPCTSTR, LPCTSTR)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx:1017:22: error: 'intptr_t' was not declared in this scope C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx:1017:32: error: expected ')' before 'TlsGetValue' C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx:1419:1: error: expected ')' at end of input C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx:1419:1: error: expected statement at end of input C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx:1419:1: error: expected '}' at end of input C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT_1.cxx: In function 'WORD* lpwAlign(LPWORD)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT_1.cxx:245:9: error: 'intptr_t' was not declared in this scope C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT_1.cxx:245:19: error: expected ';' before 'lpIn' C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_FontMgr.cxx:23:22: fatal error: ft2build.h: No such file or directory compilation terminated. C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_Context.cxx: In member function 'void* OpenGl_Context::findProc(const char*)': C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_Context.cxx:252:40: error: invalid conversion from 'PROC {aka int (__attribute__((__stdcall__)) *) ()}' to 'void*' [-fpermissive] With Visual Studio 2012 it's even better: Quote: C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_FontMgr.cxx:23:22: fatal error: ft2build.h: No such file or directory Hope this helps, and looking forward to the fixes Kel
Hi Keltor, thank you for testing The ftbuild problem is solved (I have still to upload the fix, I'll do it this evening); the other I guess depends on GCC for windows not defining intptr_t; I can do it inside package. If you're in a hurry, you can solve both opening the packge organizer and adding a couple of compilation options : 1) Add an internal include, with the value ../freetype 2) Add a compiler option, with the value -Dintptr_t=int* (second one I don't know if it works...) Ciao Max
Thanks for the speedy reply, Max! I am certainly not in a hurry Still, I tried your suggestions. Fix number 1 works no problem, fix 2 induces a few other errors here and there. I will not bore you with the details since I guess it would be more of a nuisance than a help - after all, the important thing is in the package itself. What might be helpful is the following: Since fix 1 solves the Visual Studio 2012 error, I have gone ahead and compiled the project again from scratch using that toolchain. Two points arise: - First, the VC compiler keeps saying C:\Program Files (x86)\Microsoft Visual Studio 11.0\Vc\Include\crtdefs.h(446) : warning C4091: 'typedef ' : ignored on left of '__w64 unsigned long' when no variable is declared after compiling every file - Second, the library is linked correctly, yet the OCETest executable fails because of the following: Linking... Creating library C:\upp\out\bazaar\MSVC11.Gui.Usemalloc\OCETest.lib and object C:\upp\out\bazaar\MSVC11.Gui.Usemalloc\OCETest.exp OCE.lib(Graphic3d_WNTGraphicDevice.obj) : error LNK2019: unresolved external symbol "private: void __thiscall Graphic3d_WNTGraphicDevice:: SetGraphicDriver(char const * const)" (?SetGraphicDriver@Graphic3d_WNTGraphicDevice@@AAEXQBD@Z) referenced in function "public: __this call Graphic3d_WNTGraphicDevice::Graphic3d_WNTGraphicDevice(char const * const)" (??0Graphic3d_WNTGraphicDevice@@QAE@QBD@Z) OCE.lib(OpenGl_Window.obj) : error LNK2019: unresolved external symbol __imp__InterfaceGraphic_RealizePalette referenced in function "publ ic: __thiscall OpenGl_Window::OpenGl_Window(class Handle_OpenGl_Display const &,struct CALL_DEF_WINDOW const &,void *,class Handle_Ope nGl_Context const &)" (??0OpenGl_Window@@QAE@ABVHandle_OpenGl_Display@@ABUCALL_DEF_WINDOW@@PAXABVHandle_OpenGl_Context@@@Z) C:\upp\out\bazaar\MSVC11.Gui.Usemalloc\OCETest.exe : fatal error LNK1120: 2 unresolved externals Still, it's very very close... Thanks Max for the great job!
Hi, for the second error, I already sent a patch to OCE which is being integrated. If you want to test it, there's a private branch named review/fix-static-build which contains the fixes. Sorry for the inconveniences, but OCE is in the way incorporating 6.5.4 update, so it needs some days to stabilize. BTW, with the patch I got it compiling and running or both on windows (visualc 9) and Linux (ubuntu, GCC 4.7.2). Feel free to signal more problems.... I'm a bit busy on these days, but I'm thinking to continue development of my UppCad application, so I guess I'll be faster with updates on next days. Ciao Max
Hi again Max, No need to apologise for inconveniences! On the contrary, it's the whole community that is grateful to you and to the rest of the people who make it possible for us all to reap the rewards of your hard work. Personally, I am just happy to contribute in any humble way I can if with that I can make your life a little easier, that's why I thought I would present my own experience in case it might help out. Let me make that extensive to all the really talented folks working on U++. Guys, you all rock, seriously. Back to the issue: I will certainly keep testing the new version, not only compiling it but also working with the final product, so if something comes up, I'll be sure to let you know. Thanks again, cheers, Kel
I've uploaded a demo (NON open sourced, just the executable and a test file) of the ongoing uppcad project, based on OCE libraries. It's still in early stage, but many stuffs are already working. If you want to test it, just grab these files: http://www.timberstruct.it/UppCad.exe http://www.timberstruct.it/prova.ucd (.ucd file needs to be saved on disk, so if your browser opens it, just choose 'save as' option instead) To test, just run UppCad.exe and open the Prova.ucd file. Usage is simple, only 'weird' thing is the view rotate command, which is done with CTRL+SHIFT+middle mouse button drag To see view in shaded, random colors, just select GOURAUD view mode. HIDDEN line mode is quite slow when rotating the view, as it must regenerate all hidden lines on each step. Ciao Max
Very cool .
Hi Koldo Thank you for testing. There's also a 'stepin' command (must be entered by command line) which allows to import any step file... you can find some on web or make them with some cad application. The sample above is a job drawing exported from autocad, converted to step and imported in uppcad. Ciao Max
Hi, I have retaken the project of compiling the new OCE under Windows. This time, since Massimo reports that VS works fine, with GCC 4.7.0. I am using the latest version of U++ (5584) and the review/fix-static-build source for OCE. As is, the project has a few issues: - One still needs to define the internal include ../freetype as mentioned on a previous post. - File OpenGl_Context.cxx yields an error on line 252. That can be solved either by adding a (void*) cast in front of the returned value or by adding the compiler option -fpermissive. - After those issues are solved, all files are compiled correctly, yet U++ complains that there are errors and does not proceed to the next package. To further illustrate: if I re-run the build process after that, I get the following: ----- CtrlLib ( GUI USEMALLOC GCC WIN32 ) (1 / 13) ----- OCE ( GUI USEMALLOC GCC WIN32 ) (2 / 13) Creating library... There were errors. (0:09.01) Any ideas why that is so? I will keep on at it Keltor PS: Really cool proggie, Max!
Hi Keltor, sorry, but I had no time to test and commit latest fixes to OCE... I guess I'll do it this evening. Just wait for next post, I'll tell when the fixes will be on git. Ciao Max
OK, no problem. I will wait for the next version then. In the meantime I'll take a further look at UppCad Thanks!
Hi Max, I just tried under wine. It started fine and looks very good (great icons ) But it got stuck when trying to do a move ( Wine issue )
Hi Didier... I think on next days (weeks ?) I'll setup an autoupdater on my server, both for linux and windows, so you'll be able to test it on Linux directly. It still has a couple of bugs... it does hard multithreading, and the behaviour is far from perfect.... Ciao Max
Hi Max, Very nice indeed! How about DXF import/export? And perhaps HPGL plotting? Best regards, Tom
Hi Tom, first thing I need is a SAT import.... it's needed to read 3d exported from autocad. By now I do the conversion to step wth an external app and then import the .stp file in UppCad, which is not so comfortable and looses layer/color info. I have not found any opensourced SAT reader code.... DXF is completely useless regarding 3d objects, they're encrypted inside DXF files, so unreadable without spatial libraries. I'll do of course a DXF import for simple objects, and a DXF export for 2d drawings, but the SAT reader is a must. If somebody knows about some free code to read/write sat files, I'll be very happy Max
Yes, I was looking (quite narrowly, I might add) for just 2D DXF. I did find a link to SAT format specification ... but I guess you're looking specifically for code, not spec. Anyway I put it here, just in case it is of interest to somebody: http://paulbourke.net/dataformats/sat/sat.pdf Best regards, Tom
Hi Tom... yes, I have this document, and I'm afraid I'll have to write the importer from scratch. OCC has a sat importer, but not free... pity. Max
Just updated the OCE package. UPP package is ok and builds fine on windows; you still need to fetch the review branch containing fixes for static build up to it gets merged to master; the branch is review/fix-static-build I think it'll be merged on next days. Please test and report any problems ! Ciao Max
I tried to compile under Windows with U++ 5592 and the review/fix-static-build branch. MSVC 11 builds successfully, however MINGW still complains: keltor wrote on Wed, 28 November 2012 11:54 Hi, - File OpenGl_Context.cxx yields an error on line 252. That can be solved either by adding a (void*) cast in front of the returned value or by adding the compiler option -fpermissive. - After those issues are solved, all files are compiled correctly, yet U++ complains that there are errors and does not proceed to the next package. To further illustrate: if I re-run the build process after that, I get the following: ----- CtrlLib ( GUI USEMALLOC GCC WIN32 ) (1 / 13) ----- OCE ( GUI USEMALLOC GCC WIN32 ) (2 / 13) Creating library... There were errors. (0:09.01) Any ideas why that is so? I'm a bit stumped, to be honest, since I don't understand why it compiles all files and then refuses to build the library. Is it because of OCE, MINGW or U++? Hmmmm... now it's personal I'll find a way. Of course, if someone knows the reason, I'll be very glad to hear it Kel
Hi Keltor, I don't have mingw installed, so I can't test it. Could you please do a FULL rebuild (clean packages, then rebuild them) and drop me the error output ? Ciao Max
There are no errors - just warnings. That's what puzzles me... Still, I'll dump those as soon as I finish rebuilding.
OK, so I did the following: I rebuilt with the compiler option -Werror to treat warnings as errors, then I built again without the option to filter out all files that were compiled correctly. Here's the output: ----- CtrlLib ( GUI USEMALLOC GCC BLITZ WIN32 ) (1 / 13) ----- OCE ( GUI USEMALLOC GCC WIN32 ) (2 / 13) BSplSLib.cxx OSD.cxx OSD_File.cxx OSD_FileNode.cxx OSD_Process.cxx C:\upp\bazaar\OCE\oce\src\BSplSLib\BSplSLib.cxx:43:0: warning: "M_SQRT2" redefined [enabled by default] In file included from C:\upp\bazaar\OCE\oce\inc/Standard_Real.hxx:23:0, from C:\upp\bazaar\OCE\oce\inc/Standard_PrimitiveTypes.hxx:41, from C:\upp\bazaar\OCE\oce\inc/Handle_Standard_Transient.hxx:31, from C:\upp\bazaar\OCE\oce\inc/Handle_Standard_Failure.hxx:17, from C:\upp\bazaar\OCE\oce\inc/Standard_Failure.hxx:16, from C:\upp\bazaar\OCE\oce\inc/Standard_DomainError.hxx:23, from C:\upp\bazaar\OCE\oce\inc/Standard_RangeError.hxx:23, from C:\upp\bazaar\OCE\oce\inc/Standard_OutOfRange.hxx:23, from C:\upp\bazaar\OCE\oce\inc/TCollection_Array2.lxx:19, from C:\upp\bazaar\OCE\oce\inc/TColgp_Array2OfPnt.hxx:119, from oce/drv/BSplSLib/BSplSLib.jxx:2, from oce/drv/BSplSLib/BSplSLib.ixx:6, from C:\upp\bazaar\OCE\oce\src\BSplSLib\BSplSLib.cxx:29: c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/math.h:64:0: note: this is the location of the previous definition OSD_WNT.cxx OSD_signal_WNT.cxx Resource_Manager.cxx C:\upp\bazaar\OCE\oce\src\OSD\OSD.cxx:123:0: warning: "finite" redefined [enabled by default] C:\upp\bazaar\OCE\oce\src\OSD\OSD.cxx:28:0: note: this is the location of the previous definition C:\upp\bazaar\OCE\oce\src\OSD\OSD_FileNode.cxx: In function 'void _osd_wnt_set_error(OSD_Error&, OSD_WhoAmI, ...)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_FileNode.cxx:971:27: warning: second parameter of 'va_start' not last named argument [enabled by default] C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx: In member function 'void OSD_File::Read(TCollection_AsciiString&, Standard_Integer)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx:1072:12: warning: deleting 'Standard_Address {aka void*}' is undefined [enabled by default] C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx: In member function 'void OSD_File::ReadLine(TCollection_AsciiString&, Standard_Integer, Standard_Integer&)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx:1141:36: warning: right shift count >= width of type [enabled by default] C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx:1203:36: warning: right shift count >= width of type [enabled by default] C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx: In static member function 'static OSD_File OSD_File::BuildTemporary()': C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx:1708:17: warning: deprecated conversion from string constant to 'LPTSTR {aka char*}' [-Wwrite-strings] C:\upp\bazaar\OCE\oce\src\OSD\OSD_File.cxx:1708:17: warning: deprecated conversion from string constant to 'LPTSTR {aka char*}' [-Wwrite-strings] Standard_CString.cxx C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx: In function 'BOOL MoveDirectory(LPCTSTR, LPCTSTR)': C:\upp\bazaar\OCE\oce\src\OSD\OSD_WNT.cxx:1017:59: warning: NULL used in arithmetic [-Wpointer-arith] OpenGl_Display.cxx C:\upp\bazaar\OCE\oce\src\Resource\Resource_Manager.cxx:42:0: warning: "ERROR" redefined [enabled by default] In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/windows.h:52:0, from C:\upp\bazaar\OCE\oce\inc/Standard_ThreadId.hxx:29, from C:\upp\bazaar\OCE\oce\inc/Standard_ErrorHandler.hxx:32, from C:\upp\bazaar\OCE\oce\src\Resource\Resource_Manager.cxx:30: c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/wingdi.h:313:0: note: this is the location of the previous definition C:\upp\bazaar\OCE\oce\src\OSD\OSD_Process.cxx: In member function 'OSD_Path OSD_Process::CurrentDirectory()': C:\upp\bazaar\OCE\oce\src\OSD\OSD_Process.cxx:405:65: warning: NULL used in arithmetic [-Wpointer-arith] C:\upp\bazaar\OCE\oce\src\OSD\OSD_signal_WNT.cxx:226:1: warning: deprecated conversion from string constant to '_TCHAR* {aka char*}' [-Wwrite-strings] C:\upp\bazaar\OCE\oce\src\OSD\OSD_signal_WNT.cxx:226:1: warning: deprecated conversion from string constant to '_TCHAR* {aka char*}' [-Wwrite-strings] C:\upp\bazaar\OCE\oce\src\OSD\OSD_signal_WNT.cxx:226:1: warning: deprecated conversion from string constant to '_TCHAR* {aka char*}' [-Wwrite-strings] In file included from C:\upp\bazaar\OCE\oce\src\Standard\Standard_CString.cxx:52:0: C:\upp\bazaar\OCE\oce\inc/Standard_String.hxx:38:40: warning: 'MaskEndIntegerString' initialized and declared 'extern' [enabled by default] OpenGl_Polygon.cxx InterfaceGraphic_cPrintf.cxx MFT_FontManager.cxx Graphic2d_GraphicObject.cxx C:\upp\bazaar\OCE\oce\src\InterfaceGraphic\InterfaceGraphic_cPrintf.cxx: In function 'int cPrintf(const char*, ...)': C:\upp\bazaar\OCE\oce\src\InterfaceGraphic\InterfaceGraphic_cPrintf.cxx:56:5: warning: 'int cPrintf(const char*, ...)' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] C:\upp\bazaar\OCE\oce\src\InterfaceGraphic\InterfaceGraphic_cPrintf.cxx: In function 'int fcPrintf(int, const char*, ...)': C:\upp\bazaar\OCE\oce\src\InterfaceGraphic\InterfaceGraphic_cPrintf.cxx:85:5: warning: 'int fcPrintf(int, const char*, ...)' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] C:\upp\bazaar\OCE\oce\src\InterfaceGraphic\InterfaceGraphic_cPrintf.cxx: In function 'char* GetEnv(const char*)': C:\upp\bazaar\OCE\oce\src\InterfaceGraphic\InterfaceGraphic_cPrintf.cxx:114:7: warning: 'char* GetEnv(const char*)' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] FWOSDriver_Driver.cxx C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_Display.cxx:45:36: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_Polygon.cxx: In destructor 'virtual OpenGl_Polygon::~OpenGl_Polygon()': C:\upp\bazaar\OCE\oce\src\OpenGl\OpenGl_Polygon.cxx:569:57: warning: deleting 'void* const' is undefined [enabled by default] C:\upp\bazaar\OCE\oce\src\FWOSDriver\FWOSDriver_Driver.cxx: In member function 'virtual TCollection_ExtendedString FWOSDriver_Driver::DefaultFolder()': C:\upp\bazaar\OCE\oce\src\FWOSDriver\FWOSDriver_Driver.cxx:175:23: warning: NULL used in arithmetic [-Wpointer-arith] C:\upp\bazaar\OCE\oce\src\Graphic2d\Graphic2d_GraphicObject.cxx:45:0: warning: "MAX_PRIORITY" redefined [enabled by default] In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/windows.h:87:0, from C:\upp\bazaar\OCE\oce\inc/Standard_ThreadId.hxx:29, from C:\upp\bazaar\OCE\oce\inc/Standard_ErrorHandler.hxx:32, from C:\upp\bazaar\OCE\oce\src\Graphic2d\Graphic2d_GraphicObject.cxx:41: c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/winspool.h:208:0: note: this is the location of the previous definition C:\upp\bazaar\OCE\oce\src\MFT\MFT_FontManager.cxx: In function 'void* mmap(off_t, int, int)': C:\upp\bazaar\OCE\oce\src\MFT\MFT_FontManager.cxx:339:60: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] C:\upp\bazaar\OCE\oce\src\MFT\MFT_FontManager.cxx:343:61: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] C:\upp\bazaar\OCE\oce\src\MFT\MFT_FontManager.cxx:352:58: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] OCE: 15 file(s) built in (0:11.51), 767 msecs / file, duration = 12340 msecs, parallelization 100% Creating library... There were errors. (0:12.44) As far as I can see, there are no errors as such, and despite that, the library does not get rebuilt. Weird. Hope this helps in any case. Kel
hummm... the warnings are quite normal stuff, OCC needs to be cleaned more, but we're in the way. What do you mean that library is not built ? BTW... do you use a recent IDE, right ? I posted a patch some monthes ago, about command line lenght limit when running compiler and linker... this limit was making OCE build impossible, but now it's corrected. Max
The library, despite what the quote from my last post seems to suggest, does not link properly. The files are all compiled AFAIK but the process stops there, it does not produce a valid .a file and it does not proceed to the compilation of the next module.
keltor wrote on Thu, 29 November 2012 13:14 The library, despite what the quote from my last post seems to suggest, does not link properly. The files are all compiled AFAIK but the process stops there, it does not produce a valid .a file and it does not proceed to the compilation of the next module. Please check your IDE version.... I had a similar problem some time ago and had to fix ide to be able to link large file lists. If your ide's version is more than few monthes old, please update it with last svn and retest. Max
Actually, my IDE is a few hours old... It's version 5592. Kel
I am beginning to think that the culprit may be GCC itself. Since the compiling works fine, it must be the linking. Maybe there are too many files for the linker to process at one time? Wasn't there an option to view the commands it executes while compiling? I forgot how it's done...
in setup menu, select 'be verbose' checkbox. But, are you really sure you are running an up to date ide ? this one seems really the problem I had before the command line patch... it was too long for link command. Now if cmdline is too long, it does it by a command file, so no more problems. Max
I'm positive it's new, I just installed it this morning to test for OCE. On the About box, it states that it's version 5592. I checked the ar linker command. It's over 600 KB in length so I won't paste it here: ----- OCE ( GUI USEMALLOC GCC WIN32 ) (2 / 13) cd C:\upp\bazaar\OCE Creating library... ar -sr (...) Exitcode: There were errors. (1:15.53) No exitcode apparently? Could that be the reason?
ahhhh ! I guess that one is the problem... if you look on MSC command line you'll see : cd c:\users\massimo\sources\upp-svn\bazaar\OCE Creating library... link /lib -nologo @C:\Users\Massimo\AppData\Local\Temp\4EB3709D3C0500B6545D5EB637FEBD0C.tmp I guess mingw uses another command for lib building, which is unaffected by my patch, so gets the whole (too long) commandline. Max
Great! Now we're really getting somewhere! It was driving me nuts I'll leave it in your capable hands then Or we can just use MSVC after all... Thanks Massimo, Kel
keltor wrote on Thu, 29 November 2012 16:55 I'll leave it in your capable hands then Kel sigh... another IDE patch. I'll take a look at it, but I don't have mingw setup handy, so you'll have to test it. Max p.s.: could you please test my UppCad in the meanwhile ? If you find a reproductible crash, please tell me... I'm fixing last bgs before extending it. http://www.timberstruct.it/UppCad.exe Max
Absolutely! I have already looked at it, but not yet in depth. So I'll be sure to do that. From what I have gathered so far, it looks very impressive. And of course I'll be glad to test any patches regarding the OCE issue as well. Keltor
Thank you... I'll keep updating the link above for few days; when it'll be a bit more usable, I'll setup the autoupdate server for it. After last patch I didn't find any more crashes, but I'd like to have it stable before adding features... otherwise it will be more difficult to find bugs. If you can, please play with more document at the same time, the difficult part was the multithreading stuff. You can copy the test drawing or, if you prefere, I can post more samples. Max
It would be nice, but certainly it's not essential, to have another .ucd file. In any case, I'll test the multithreading thoroughly between today and tomorrow. So far, I can tell you something I have seen. Not a bug in itself, but something that can be a little odd to the end user. It seems that there are options that involve calling two consecutive commands, e.g. Shade - Gouraud. A right-click seems to repeat the last command, so if one right-clicks after a two-step command, only the last line gets repeated (in this case, Gouraud), which results in an error. A minor thing, really, but just so you know. I'll tell you any other, major or minor, issues that I find, especially when working with several files at the same time. Kel
Hi Keltor, please update your IDE with last svn and recheck... I've duplicated my patch of MSC builder to GCC one, now a command file is used if commandline length is > 8192 bytes, which is the limit for windows. Ciao Max
Ciao Max, Creating library... ar -sr "C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a" @C:\Users\Keltor\AppData\Local\Temp\0A0002723654FF90249AAD0716804E0D.tmp C:\MinGW\bin\ar.exe: creating C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a C:\MinGW\bin\ar.exe: C:/upp/out/bazaar/OCE/MINGW.Gui.UsemallocDynamic.o: No such file or directory C:\MinGW\bin\ar.exe -sr "C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a" @C:\Users\Keltor\AppData\Local\Temp\0A0002723654FF90249AAD0716804E 0D.tmp Error executing C:\MinGW\bin\ar.exe -sr "C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a" @C:\Users\Keltor\AppData\Local\Temp\0A0002723654FF 90249AAD0716804E0D.tmp Exitcode: 1 It seems to me that you are missing a slash at the end of the directory name, e.g. MINGW.Gui.Usemalloc/Dynamic.o Apart from that, I still had to change line 252 from file OpenGl_Context.cxx to read Quote: return (void*)wglGetProcAddress (theFuncName); Either that or add the GCC compiler option -fpermissive. Although to be fair, I didn't update the OCE source today, so I don't know for sure if that change is commited or not. Almost there, in any case. On to the UppCad report. The newest version is much more stable, it doesn't crash as often when multiple files are open. What I encountered, though, is that it got stuck when I tried to erase an object. Certainly going in the right direction, though. Keep up the good work! Kel
uhmmm... I guess I have to install mingw Well, this afternoon, maybe. I just took the command line end part and put it on a command file, but maybe I missed something. Max
Ok, fixed for Mingw too... please retest with latest svn. The (void *) bug is still there, I posted a message on OCE site about it; the static build fix is also still not merged, but it should be so in few time. Max
Retried OCETest with version 5609 and MinGW. The library gets built correctly (yay!). The linking of the OCETest executable itself, however, yields a few errors: C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(OSD_File.o):OSD_File.cxx:(.text$_Z10_osd_printPcPKc+0x28): undefined reference to `OpenPri nterA@12' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(OSD_File.o):OSD_File.cxx:(.text$_Z10_osd_printPcPKc+0x64): undefined reference to `AddJobA @20' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(OSD_File.o):OSD_File.cxx:(.text$_Z10_osd_printPcPKc+0xb8): undefined reference to `GetJobA @24' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(OSD_File.o):OSD_File.cxx:(.text$_Z10_osd_printPcPKc+0xe4): undefined reference to `SetJobA @20' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(OSD_File.o):OSD_File.cxx:(.text$_Z10_osd_printPcPKc+0xf6): undefined reference to `ClosePr inter@4' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(OSD_File.o):OSD_File.cxx:(.text$_Z10_osd_printPcPKc+0x14d): undefined reference to `Schedu leJob@8' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(PlotMgt.o):PlotMgt.cxx:(.text$_ZN7PlotMgt10DeviceListEv+0x150): undefined reference to `En umPrintersA@28' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(PlotMgt.o):PlotMgt.cxx:(.text$_ZN7PlotMgt10DeviceListEv+0x1bd): undefined reference to `En umPrintersA@28' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(PlotMgt.o):PlotMgt.cxx:(.text$_ZN7PlotMgt10DeviceListEv+0x27e): undefined reference to `En umPrintersA@28' C:/upp/out/bazaar/OCE/MINGW.Gui.Usemalloc\OCE.a(PlotMgt.o):PlotMgt.cxx:(.text$_ZN7PlotMgt10DeviceListEv+0x2eb): undefined reference to `En umPrintersA@28' C:/upp/out/bazaar/OCE/WNT/MINGW.Gui.Usemalloc\WNT.a(WNT_DDriver.o):WNT_DDriver.cxx:(.text$_ZN11WNT_DDriver10DeviceListEv+0x150): undefined reference to `EnumPrintersA@28' C:/upp/out/bazaar/OCE/WNT/MINGW.Gui.Usemalloc\WNT.a(WNT_DDriver.o):WNT_DDriver.cxx:(.text$_ZN11WNT_DDriver10DeviceListEv+0x1bd): more unde fined references to `EnumPrintersA@28' follow Or perhaps I need to use different OCE source files?
I don't know, I had same linking issue with mingw. I'll test it deeply on next days with mingw, on OCE site they're testing many patches related to mingw. Max
Hi, I have updated the UppCad application with some extensions; I'll be glad if somebody will test it. Here the links, both for windows and linux, with the usual demo drawing. Please DON'T use old demo drawing, file format is changing and they're probably incompatible. Please test in detail the layers/materials/textures part; to look at textured drawing, just push the dark "textured" box icon near bottom. There are now layers, materials and texture editors. If you want to use other textures with the demo file, keep in mind that too big images will lead to long render times. Embedded ones are a compromise between quality and size. You can turn on/of some layers to look, for example, to iron parts in detail. It can be done through the layer control on top. You can also draw something on a new drawing; few commands are working, just test; recently added are SPHERE and CONE. Look also at settings menu to enable snaps. Coordinates can be entered also by command line (quite similar to autocad). <ESC> key interrupts current command. Undo and redo are available by command line and menu items. Added also a step import command, both via command line and menus. windows : http://www.timberstruct.it/UppCad.exe linux (64 bit) : http://www.timberstruct.it/UppCad demo file : http://www.timberstruct.it/Frige.ucd small demo steel part : http://www.timberstruct.it/Ferro.ucd small demo with some other textured elements : http://www.timberstruct.it/Prova.ucd In short time I'll update the OCE package to 0.11 version, with all bug fixes embedded. Please report any crash (it's still not perfect, but quite stable now). Ciao Max EDIT : OCE is available now in 0.11 version with all bugfixes, so it shouldn't be necessary to fetch my private GIT branches. Just a git clone on master branch is enough. UppCad also updated here, with many enhancements and bugfixes. Ciao Max
I have tried to compile version 0.11 with MinGW and I get the same linking problem as before. Also, the intptr_t error is back... That last part can be solved by adding an #include <stdint.h> in the offending files. I have also tried UppCad and I would say it's stable now. I have tried several files at the same time and the few crashes that happened to me before seem to be solved. It has not crashed a single time yet. Good job Massimo!
keltor wrote on Wed, 12 December 2012 18:17 I have tried to compile version 0.11 with MinGW and I get the same linking problem as before. Also, the intptr_t error is back... That last part can be solved by adding an #include <stdint.h> in the offending files. I have also tried UppCad and I would say it's stable now. I have tried several files at the same time and the few crashes that happened to me before seem to be solved. It has not crashed a single time yet. Good job Massimo! Hi Keltor First of all, thank you for testing, I really needed it. Then... about Mingw, are you using the 32 or 64 bit version ? Because I know there are problems with the 64 bit, and hereI've just a 32 bit one for testing. I'll try again tomorrow, I guess, to solve these problems. Ciao Max
You're very welcome, Max, my pleasure, really. Sorry it took so long though, I have been really busy these days. I am using MinGW GCC 4.6.2 32 bit. I have also tried with TGM-GCC 4.7.0 32 bit with similar results.