Hi Thomas,
Man, I'm so mad at myself!! I wish I didn't waste so much time compiling
Salome!
Ok I compiled and installed salomegeometry without any problem.
Now I am trying to compile pythonOcc trunk (as you told me 0.3 doesn't
support 64 bits- yet the -march=X86_64 error remains but easy to solve).
It quickly get on a weird casting error - see attached log file.
I could try to investigate it by myself and find a work around, but I guess
you will better know how to solve it.
Thanks for your help.
Loïc.
On Fri, Sep 18, 2009 at 10:41 AM, Thomas Paviot <tpav...@gmail.com> wrote:
> 2009/9/18 Simon Loic <simon1l...@gmail.com>
>
>> Hi,
>>
>
> Hi Simon,
>
>
>> I'm new to PythonOcc, and found it very promising. Thanks for the work.
>>
>
> Welcome on board!
>
>
>> However it took me more than 3 days to make it compile and I'm not
>> finished yet.
>>
>
> Ouch. You should have ask a few questions on this forum earlier, this delay
> would have been shortened to 1 day max. I guess the following lines of your
> message are related to the compilation of both OCC/GEOM/pythonOCC on Ubuntu
> 9.04 64 bits. It's actually an excellent news: I've been trying to do the
> same under MacOSX Snow Leopard 64 bits (I recently moved from my old
> Dell/Windows laptop from a new MacBook Pro). Untill the 0.3 release,
> pythonOCC was developed with 32 bits systems, whether they are Windows or
> Linux based. The 64 bits compilation require a few hacks over the current
> pythonOCC code. I finally got OCC/pythonOCC running with 64 bits support,
> but the code is currently only available on the svn repository. The
> environment.py and setup.py scripts were modified to enable 64 bits support,
> but I still miss a few feedbacks from Win64 and Lin64 users.
>
>
>> Still I would like to share my experience to make it smoother for new
>> users and also for myself to get useful info.
>> You may think I am did a lot of crap so that it takes me 3 days!!! Well
>> this the story:
>> I took support on the wiki page:
>> http://www.pythonocc.org/wiki/index.php/Installing_pythonOCC_on_Linux
>> and checked out the http://svn.gna.org/svn/pythonocc/tags/0.3 revision of
>> pythonOcc.
>>
>> - As explained, I had to install OCC (1 day of hard struggle until I found
>> the pythonOcc wiki page
>> http://www.pythonocc.org/wiki/index.php/Installing_OpenCASCADE_on_Linux!<http://www.pythonocc.org/wiki/index.php/Installing_OpenCASCADE_on_Linux%21>
>> !)
>>
>
> This step normally goes without any problem.
>
> - Then a first missing (or not very clear) info is that you need to have
>> the Geom module of Salome installed in order for the compilation to work
>> (otherwise you have to specify -NO_GEOM and you get less functionalities)
>> - I thought that as only the GEOM module was required I would build it
>> from source : Such a huge mistake!!! their building scripts are based on
>> automake&co and need tons of environment variable to be specified so as for
>> the 3rd party libs to be found!! Actually I didn't make it work, until I
>> discovered that they had a hidden script allowing to use CMake. Afterwards
>> everything was just pleasure. (this step took me almost 2 days.
>>
>
> NO! It's certainly my fault since you took the wrong way, but you MUST NOT
> use the GEOM module from Salomé. Salomé is a real mess, and pythonOCC is
> based upon the GEOM module extracted from Salomé (and then independant from
> it). You MUST download/install rev.175 of the salomegeometry project (
> http://sf.net/projects/salomegeometry). It's very easy to get it compile
> under Linux (a few minutes). I will upload to the wiki a simple Howto (I
> realize it's missing, sorry).
>
>
>> - Besides, another info was missing in the wiki : one have to set the env
>> variable SALOME_GEOM_LIB to the path where to find the GEOM libraries.
>> - That's not all, some of the Geom library names seems to have change
>> (that's my own explanation for what follows) as I had to change in setup.py
>> Sketcher by GEOMSketcher
>> GEOMImpl by GEOMimpl (downcase the i)
>> Archimede by GEOMArchimede
>> - Also, the fact that some headers have been renamed SGEOM_yyy.hxx is a
>> problem (i know it was done because of some windows conflicting behaviour)
>> because some of the functionalities have become inline (declaration is in
>> the header) in the last sources of Salome (5.1.2). So you get some undefined
>> reference to XXX::YYY(). As a consequence I had to regenerate cpp wrap files
>> (-generate_swig). And actually it's still running, I'm not sure it will
>> succeed)
>>
>
> Same thing: rather user salomegeometry.
>
>
>> - Finally, there is a small problem with the environment.py file :
>> platform.machine() returns x86_64 which is invalid for g++ -march flag (
>> expects "x86-64 apparently).
>>
>
> Ok, thanks.
>
>
>>
>> I've attached a file patch.txt, but it's rather a summary of the
>> workaround I had to use than a real fix. Maybe some of these problems have
>> been solved in the trunk, or are just due to a misunderstanding from me. In
>> this case I hope some folks will correct the concerned points. And of course
>> I wish I can make it compile finally!!!
>> Cheers,
>>
>>
> Regards,
>
>
>> Loïc
>>
>
> Thomas
>
>
> _______________________________________________
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
Building pythonOCC-path_to_0.4 for linux2.
running build
running build_py
package init file 'OCC/__init__.py' not found (or not a regular file)
copying OCC/MoniTool.py -> build/lib.linux-x86_64-2.6/OCC
package init file 'OCC/__init__.py' not found (or not a regular file)
running build_ext
building 'OCC._MoniTool' extension
swigging /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool.i to /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp
swig -python -python -modern -fcompact -c++ -DHAVE_LIMITS_H -DHAVE_CONFIG_H -DCSFDB -w302,314,509,512 -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -outdir /home/matador/Desktop/Code/pythonOCC/src/OCC -o /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool.i
g++ -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DHAVE_CONFIG_H -DHAVE_LIMITS_H -DCSFDB -DOCC_CONVERT_SIGNALS -DLIN -DLININTEL -D_GNU_SOURCE=1 -D__PYTHONOCC_MAXINT__=2147483647 -I/opt/OpenCASCADE6.3.0/inc -I/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin -I/usr/include/python2.6 -c /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp -o build/temp.linux-x86_64-2.6/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.o -O0 -march=x86-64
cc1plus: attention : l'option de la ligne de commande "-Wstrict-prototypes" est valide pour Ada/C/ObjC mais pas pour C++
Dans le fichier inclus à partir de /opt/OpenCASCADE6.3.0/inc/Standard_Macro.hxx:11,
à partir de /opt/OpenCASCADE6.3.0/inc/Standard_TypeDef.hxx:13,
à partir de /opt/OpenCASCADE6.3.0/inc/Standard_Address.hxx:17,
à partir de /opt/OpenCASCADE6.3.0/inc/Standard.hxx:26,
à partir de /opt/OpenCASCADE6.3.0/inc/Standard_Failure.hxx:27,
à partir de /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp:3097:
/opt/OpenCASCADE6.3.0/inc/config.h:41:1: attention : « HAVE_FINITE » redéfini
Dans le fichier inclus à partir de /usr/include/python2.6/Python.h:8,
à partir de /home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp:145:
/usr/include/python2.6/pyconfig.h:179:1: attention : ceci est la localisation d'une précédente définition
/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp: In function ‘PyObject* _wrap_MoniTool_DataMapNodeOfDataMapOfTimer_Key(PyObject*, PyObject*)’:
/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp:7297: erreur: invalid initialization of reference of type ‘char*&’ from expression of type ‘const char*’
/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp: In function ‘PyObject* _wrap_MoniTool_DataMapIteratorOfDataMapOfTimer_Key(PyObject*, PyObject*)’:
/home/matador/Desktop/Code/pythonOCC/src/wrapper/SWIG/linux_darwin/MoniTool_wrap.cpp:11072: erreur: invalid initialization of reference of type ‘const char*&’ from expression of type ‘const char* const’
error: command 'g++' failed with exit status 1
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
