Arthur Magill a écrit : > Okay, here are a couple more tweaks: Hi Arthur, > > src/Visualization/Display2d.cpp > src/Visualization/Display3d.cpp > src/Visualization/NISDisplay3d.cpp > > all need to pull in cstdlib to use getenv(). I added > > #include <cstdlib> and cured that problem. I added #include <cstdlib> to Visualization.h. > > Then I get the following > > g++ -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic > -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC -DHAVE_CONFIG_H > -DHAVE_LIMITS_H -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL > -D_GNU_SOURCE=1 -I/usr/local/occ63/inc > -I/home/magill/occ/pythonOCC_132/src/Visualization > -I/usr/include/python2.5 -c > /home/magill/occ/pythonOCC_132/src/Visualization/Display2d.cpp -o > build/temp.linux-i686-2.5/home/magill/occ/pythonOCC_132/src/Visualization/Display2d.o > > -O0 > /home/magill/occ/pythonOCC_132/src/Visualization/Display2d.cpp: In > member function ‘void Display2d::Init(int)’: > /home/magill/occ/pythonOCC_132/src/Visualization/Display2d.cpp:54: > error: ‘class Xw_Window’ has no member named ‘SetFlags’ > /home/magill/occ/pythonOCC_132/src/Visualization/Display2d.cpp:54: > error: ‘WDF_NOERASEBKGRND’ was not declared in this scope > error: command 'g++' failed with exit status 1 > > Looking at the code, I'm a bit confused - is this Windows only code? I > tried moving the line > > myWindow->SetFlags(WDF_NOERASEBKGRND); > > up into the WNT part of the #ifdef and it seems to compile now. Moved to WNT part. > > Compiling now completes, and install goes without trouble. I thought > maybe this was it, but then in python I hit: > > >>> from OCC import * > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "OCC/Standard.py", line 6, in <module> > import _Standard > ImportError: No module named _Standard > > I've no idea what to do with this one :-( The _Standard.so library is not found. It must be in the same folder than the Standard.py script. > > But we're really close now! > Thaks for all. Your changes are committed to svn repository. > Arthur Cheers,
Thomas > > Thomas Paviot wrote: >> Hi Arthur, >> >> I fixed the http svn repository URL (it was just a type mistake). >> >> Thomas >> >> Arthur Magill a écrit : >>> Nice work Thomas! 75% is impressive. I'll try and check it out this >>> evening. >>> >>> BTW, the svn co instruction on the pythonOCC homepage is broken - >>> the capitals in the path break it (on Linux at least). >>> >>> svn co http://svn.gna.org/svn/pythonOCC/trunk pythonOCC >>> >>> should read >>> >>> svn co http://svn.gna.org/svn/pythonocc/trunk pythonOCC >>> >>> (I think maybe you've just fixed the SVN version and forgot HTTP?) >>> >>> Arthur >>> >>> >>> Thomas Paviot wrote: >>>> Dear All, >>>> >>>> Thanks to all your precious advices and reports, I committed a lot >>>> of changes to the subversion repository. >>>> >>>> Here are these change available in the latest svn revision (132): >>>> >>>> - I fixed broken modules (XSControl, IGESContrl, STEPControl and >>>> IGESToBRep) that failed to compile. pythonOCC for Linux is now a >>>> set of 293 modules covering almost 75% of the OpenCascade API. >>>> Attached are the stats generated from the Module.PythonOCCStats() >>>> function: a cross means that the related OCC package is wrapped in >>>> PythonOCC. Some important module are still missing for Linux but I >>>> currently work to make them all available, >>>> >>>> - the InteractiveViewer should work (the import OCC.NIS statement >>>> is optional and Windows sepecific). Note that the InteractiveViewer >>>> requires that pythonOCC is in your sys.path, >>>> >>>> - the scons script includes changes from Marco and Arthur (the >>>> Visualization.i and Misc.i still need to be added), >>>> >>>> - a huge improvement over previous release was achieved: important >>>> memory leaks that caused segfaults are fixed (in a few words, the >>>> default destructor has been overloaded. I plan to write a special >>>> e-mail to explain this stuff because it's very important and >>>> related to Python/OpenCascade memory management conflicts). While >>>> testing pythonOCC, you should then see information messages telling >>>> that the custom destructor was called. I plan to remove these >>>> messages when the debug phase is finished. >>>> >>>> To chek this out: >>>> >>>> svn update >>>> cd src >>>> python setup.py build *or* scons >>>> >>>> Best Regards, >>>> >>>> Thomas >>>> >>> > > _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
