Mon, 06/06/2005 - 17:52
Forums:
Hi,
after successfully building the Salome kernel (I just couldn't get "make install" to work) I'm yet unable to build any extension. Configure runs fine with every prerequisite getting a "yes" but when I did type make the first problem was "No rule to create target SALOME_ComponentSK.cc ..." I could work around this by copying all kernel .idl files into
I'm open for any hints on the subject.
Torsten
Mon, 06/06/2005 - 18:12
Another try solved it. I had to cp the kernel idls AND includes to the components source directory before running configure.
Torsten
Tue, 06/07/2005 - 19:51
Hi!
It is very interesting that you managed to get SALOME to compile on Debian (which version?).
Could you explain the steps involved in doing this.
Bernt-Ola
Wed, 06/08/2005 - 14:02
I did manage to get Salome Kernel to compile on Debian testing. Unluckily I didn't manage to compile anything else due to dependency problems in the autoconf generated Makefiles. The whole build process seems to be fubar. To try for yourself see my attached build.sh. You need a working OpenCASCADE5.2, a self installed vtk4.2 and qwt-0.41 and swig-1.3.17. Other stuff comes from Debian. Some is mentioned in the file but the list is not complete. If you stumble over a missing file search for it in the Debian web interface. If you happen to be able to run "make install" tell me how you did it. If you have more problems (no doubt you will) don't hesitate to ask.
Torsten
#!/bin/sh
#Debian packages
#hdf5-serial
#hdf5-tools
#libomniorb4
#libomniorb4-dev
#libomnithread3
#libomnithread3-dev
#omniidl4
#omniidl4-python
BASE=`pwd`
export KERNEL_ROOT_DIR=$BASE/kernel_install
export SWIG_ROOT=${BASE}/../SWIG-1.3.17
export PATH=${SWIG_ROOT}/bin:${PATH}
export SWIG_LIB=${SWIG_ROOT}/lib/swig1.3
export VTKHOME=/usr
export QTDIR=/usr
export QWTHOME=$BASE/../qwt-0.4.1
export HDF5HOME=/usr
export CASROOT=/usr/opt/OpenCASCADE5.2/ros
export LD_LIBRARY_PATH=${CASROOT}/lin/lib:${LD_LIBRARY_PATH}
# Variable for Foundation Classes :
export CSF_UnitsLexicon=${CASROOT}/src/UnitsAPI/Lexi_Expr.dat
export CSF_UnitsDefinition=${CASROOT}/src/UnitsAPI/Units.dat
# Variable for DataExchange :
export CSF_SHMessageStd=${CASROOT}/src/SHMessageStd
export CSF_XSMessage=${CASROOT}/src/XSMessage
# Variable for Font :
export CSF_MDTVFontDirectory=${CASROOT}/src/FontMFT
export CSF_MDTVTexturesDirectory=${CASROOT}/src/Textures
export BOOSTDIR=/usr
export OMNIORBDIR=/usr
export MED2HOME=$BASE/../med_fichier2.2.2.src
#export LD_LIBRARY_PATH=${BASE}/../med_fichier2.2.2.src/lib:${LD_LIBRARY_PATH}
mkdir -p kernel_build
mkdir -p kernel_install
export LDFLAGS="-Wl,-rpath=$CASROOT/Linux/lib -Wl,-rpath=$QWTHOME/lib"
cd KERNEL_SRC_2.2.2
./build_configure
cd ../kernel_build
../KERNEL_SRC_2.2.2/configure --prefix=${BASE}/kernel_install
Mon, 06/13/2005 - 08:48
I have gotten part way through the process for Debian-testing... (more messages including details to come...)
The first thing that tripped me up was SIP - the link on http://www.salome-platform.org/tech_req.php is NOT correct (not to mention that I couldn't find the package referred to on that page!). The required SIP is for generating python/C++ bindings - do an 'apt-get install sip4'
I was also not using the right version of automake (for versions, see the script inside CAS-5.2-patch.tar.gz at http://www.salome-platform.org/tech_req.php). I had the right versions of autoconf and libtool, but had to download and compile automake.
med2 tripped me up, because I kept thinking this referred to MED_SRC_2.2.2 in the tarball... but it is a separate package. Once I realized that, it was still a pain to find it. It's on the Code_Aster website (french), download here: http://www.code-aster.org/telechargement/tele_prod.php?prod=med&liste=all
Mon, 06/13/2005 - 09:12
Sorry about the duplicate post..
Note on previous message: to use automake185, you must set PATH=/path/to/am185/bin:${PATH}
Put it in a shell script, you'll probably need to make several attempts before everything works well.
Other packages I compiled:
(some of these are only mentioned within configure scripts... I haven't gotten past KERNEL_SRC_2.2.2, other parts of salome may need other packages.) Some may not be necessary... OTOH I may need some I skipped... we'll find out eventually.
boost_1_32_0 NOTE you must use jam (included) to build, I don't remember the details, see one of the included html files.
hdf5-1.6.3 I configured with some option that has to do with C++... maybe --enable-cxx, not sure it was necessary. Did not compile for any parallel libraries (i.e. mpich)
qt-x11-free-3.3.3 -- the tech requirements page says it works with 3.0.5; in the configure file it shows that it also works with 3.3.3 (it ONLY works with these versions because it has to patch around a bug in qt) - 3.3.3 isn't currently avaliable in debian-testing, so I had to build it.
VTK and VTK-Data - I had trouble with the native version, so I built it myself.
----------
While I think of it, if you have questions for me I'll see them more quickly if you use my e-mail: mpictor!aT!yahoo!doT!com
Mark
Mon, 06/13/2005 - 09:30
I'm building out of source... files layed out as such:
/opt/salome/ -- everything salome-related under here
/opt/salome/src/ -- all source tarballs here,
" hdf5-1.6.3/
" salome222/
" boost_1_32_0/
etc.
/opt/salome/build/ -- identical folders to src/, build everything under here.
/opt/salome/install/ --binaries go in folders here.
(doing it this way makes for easy clean-up after failed attempts)
In a console:
cd /opt/salome/build/salome222/KERNEL_SRC_2.2.2
/opt/salome/src/salome222/KERNEL_SRC_2.2.2/configure \
--prefix=/opt/salome/install/salome222/KERNEL_SRC_2.2.2
Then, in the same directory, run make. If that works, make install.
Mon, 06/13/2005 - 09:42
The whitespace of the previous message got messed up. The lines starting with a " are supposed to mean: /opt/salome/src/hdf5-1.6.3 (and so on)
---------------
A script to set up the build environ:
Contents of salenv.sh:
#!/bin/bash
cd /opt/salome
export PATH=/opt/salome/install/automake-1.8.5/bin:${PATH}
#some, but not all, of these come from
#KERNEL_SRC_2.2.2/doc/salome/DevelopersGuide.pdf
export BOOSTDIR=/opt/src/boost_1_32_0
export QTDIR=/opt/salome/install/qt
export PATH=/opt/salome/install/qt/bin:$PATH
export LD_LIBRARY_PATH=/opt/salome/install/qt/lib:$LD_LIBRARY_PATH
export HDF5HOME=/opt/salome/install/hdf5-1.6.3
export VTKHOME=/opt/salome/install/VTK
export CASROOT=/opt/occ52
export PATH=/opt/occ52/bin:$PATH
export LD_LIBRARY_PATH=/opt/occ52/lib:$LD_LIBRARY_PATH
#not sure this last line is necessary... had a lot of trouble finding Standard_Types.h,
#turned out it was because configure couldn't find config.h, which had just been
#created...!
export QWTHOME=/usr/lib
export QWT_INCLUDES=/usr/include/qwt
#Don't need PYTHONHOME=
export PYQT_SIPS=/usr/share/sip/qt/qt
export OMNIORB_CONFIG=/opt/salome/omniORB.cfg
export MED2HOME=/opt/salome/install/med_fichier2.2.2
#not listed in the pdf: med2home, boostdir
Mon, 06/13/2005 - 10:19
A problem I ran into, maybe because I am building out of source:
configure would fail on detection of Standard_Type.hxx:
[...]
config.status: creating ./salome_adm/unix/config.h
checking Standard_Type.hxx usability... no
checking Standard_Type.hxx presence... no
checking for Standard_Type.hxx... no
no
configure: WARNING: Opencascade libraries not found
[...]
Solution - export CPPFLAGS=-I/opt/salome/build/salome222/KERNEL_SRC_2.2.2/salome_adm/unix
before running configure. salome_adm/unix may not exist at first, but it doesn't matter. This will allow gcc to find config.h, apparently it's necessary to compile with Standard_Types.hxx. (GCC is used for both usability and presense checks on that header)
Before I did this, *EVERY* time I ran configure, it said that config.h did not exist... some of those times it did! Now it finds it if it does exist.
--------------------------
During make -- omniidl causes error:
[...]
make[2]: Entering directory `/opt/salome/build/salome222/KERNEL_SRC_2.2.2/idl'
/usr/bin/install -c -d ../lib/python2.3/site-packages/salome
/usr/local/bin/omniidl -bpython -I/usr/local/idl -I../salome/idl -C../lib/python2.3/site-packages/salome ../idl/salome/SALOME_Exception.idl
omniidl: Could not import back-end 'python'
omniidl: Maybe you need to use the -p option?
omniidl: (The error was 'No module named python')
make[2]: *** [../lib/python2.3/site-packages/salome/SALOME_Exception_idl.py] Error 1
[...]
Solution: change build/salome222/KERNEL_SRC_2.2.2/idl/Makefile
--> add -p/usr/lib/python2.3/site-packages/omniidl_be to OMNIORB_IDLPYFLAGS
Mon, 06/13/2005 - 10:22
make now runs a little longer, then I get the following:
[...]
cd SALOMELocalTrace ; make lib
make[3]: Entering directory `/opt/salome/build/salome222/KERNEL_SRC_2.2.2/src/SALOMELocalTrace'
../../libtool --mode=compile g++ -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DHAVE_SOCKET -I/opt/salome/build/salome222/KERNEL_SRC_2.2.2/salome_adm/unix -pthread -I../../include/salome -I/opt/salome/src/salome222/KERNEL_SRC_2.2.2/src/SALOMELocalTrace -I. -I/usr/local/include -I/usr/local/include/omniORB4 -I/usr/local/include/COS-c /opt/salome/src/salome222/KERNEL_SRC_2.2.2/src/SALOMELocalTrace/LocalTraceCollector.cxx
g++ -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DHAVE_SOCKET -I/opt/salome/build/salome222/KERNEL_SRC_2.2.2/salome_adm/unix -pthread -I../../include/salome -I/opt/salome/src/salome222/KERNEL_SRC_2.2.2/src/SALOMELocalTrace -I. -I/usr/local/include -I/usr/local/include/omniORB4 -I/usr/local/include/COS -c /opt/salome/src/salome222/KERNEL_SRC_2.2.2/src/SALOMELocalTrace/LocalTraceCollector.cxx -fPIC -DPIC -o LocalTraceCollector.lo
In file included from /opt/salome/src/salome222/KERNEL_SRC_2.2.2/src/SALOMELocalTrace/LocalTraceCollector.cxx:28:
/opt/salome/build/salome222/KERNEL_SRC_2.2.2/salome_adm/unix/sstream:36: error:conflicting
types for `struct std::stringbuf'
/usr/include/c++/3.3/iosfwd:141: error: previous declaration as `typedef struct
std::basic_stringbuf, std::allocator >
std::stringbuf'
/opt/salome/build/salome222/KERNEL_SRC_2.2.2/salome_adm/unix/sstream:90: error:syntax
error before `;' token
/opt/salome/build/salome222/KERNEL_SRC_2.2.2/salome_adm/unix/sstream:37: error:destructor
`stringbuf' must match class name `basic_ios'
[...]
?????????
I haven't tried much on this one...
Mark
Wed, 07/27/2005 - 19:09
I tried as well to compile salome on Debian testing 3.1
I went through the similar difficulties you have been to (Thx for the post you left, it helps a lot).
However I'm stuck at the compilation of LocalTraceCollector.cxx where definition of struct std::stringbuf conflict with /usr/include/c++/3.2.3/iosfwd
I tried to compile with gcc3.3 and then gcc3.2 but the same error always occur.
How did you pass that step? There is an issue with sstream but I have no idea where to look at.
Thx
Benjamin
Here is the log of the compilation.
make[3]: Entering directory `/usr/local/src/SALOME_2.2.2/KERNEL_BUILD/src/SALOME
LocalTrace'
../../libtool --mode=compile g++ -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wr
eturn-type -Wmissing-declarations -Wunused -DOMNIORB_VERSION=4 -D__x86__ -D__li
nux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -DHAVE_SOCKET -I/usr/local/src/SALOM
E_2.2.2/KERNEL_BUILD/salome_adm/unix -pthread -I../../include/salome -I/usr/loc
al/src/SALOME_2.2.2/KERNEL_SRC_2.2.2/src/SALOMELocalTrace -I. -I/usr/include -I/
usr/include/omniORB4 -I/usr/include/COS -c /usr/local/src/SALOME_2.2.2/KERNEL_S
RC_2.2.2/src/SALOMELocalTrace/LocalTraceCollector.cxx
g++ -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wmissing-declarati
ons -Wunused -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOM
P_CORBA_LONG -DHAVE_SOCKET -I/usr/local/src/SALOME_2.2.2/KERNEL_BUILD/salome_adm
/unix -pthread -I../../include/salome -I/usr/local/src/SALOME_2.2.2/KERNEL_SRC_2
.2.2/src/SALOMELocalTrace -I. -I/usr/include -I/usr/include/omniORB4 -I/usr/incl
ude/COS -c /usr/local/src/SALOME_2.2.2/KERNEL_SRC_2.2.2/src/SALOMELocalTrace/Loc
alTraceCollector.cxx -fPIC -DPIC -o LocalTraceCollector.lo
In file included from /usr/local/src/SALOME_2.2.2/KERNEL_SRC_2.2.2/src/SALOMELoc
alTrace/LocalTraceCollector.cxx:28:
/usr/local/src/SALOME_2.2.2/KERNEL_BUILD/salome_adm/unix/sstream:36: conflicting
types for `struct std::stringbuf'
/usr/local/include/c++/3.2.3/iosfwd:110: previous declaration as `typedef
struct std::basic_stringbuf,
std::allocator > std::stringbuf'
/usr/local/src/SALOME_2.2.2/KERNEL_BUILD/salome_adm/unix/sstream:90: syntax
error before `;' token
/usr/local/src/SALOME_2.2.2/KERNEL_BUILD/salome_adm/unix/sstream:37: destructor
`stringbuf' must match class name `basic_ios'
/usr/local/src/SALOME_2.2.2/KERNEL_BUILD/salome_adm/unix/sstream:37: `virtual
std::basic_ios >::~basic_ios()' and `void
std::basic_ios<_CharT, _Traits>::basic_ios() [with _CharT = char, _Traits =
std::char_traits]' cannot be overloaded
Tue, 12/13/2005 - 10:52
Well it's been a while since I checked in here...
I got around this by deleting salome's version of sstream, replacing it with a symlink to the system sstream. IIRC either configure or make create/over-write this, you may need to mess with the permissions to make it permanent.
I never got much farther, I ran into more errors and had no clue how to get around them... plus I found caelinux.org, which has salome on a livedvd.
Bob
Mon, 06/13/2005 - 16:23
Hi Mark,
I did build my OCC without autoconf. That's why config.h is missing. But it is possible to simply symlink OpenCASCADE5.2/wok/lib/config.h into OpenCASCADE5.2/ros/inc. The omniidl python backend is in the Debian package omniidl4-python.
Cheers, Torsten
Tue, 06/14/2005 - 03:21
The missing config.h was for salome, not OCC. Everything I've posted so far, I did before reading your notes on building. I replied to this thread since it seemed related - sorry for the confusion.
Mark
Mon, 06/13/2005 - 08:49
I have gotten part way through the process for Debian-testing... (more messages including details to come...)
The first thing that tripped me up was SIP - the link on http://www.salome-platform.org/tech_req.php is NOT correct (not to mention that I couldn't find the package referred to on that page!). The required SIP is for generating python/C++ bindings - do an 'apt-get install sip4'
I was also not using the right version of automake (for versions, see the script inside CAS-5.2-patch.tar.gz at http://www.salome-platform.org/tech_req.php). I had the right versions of autoconf and libtool, but had to download and compile automake.
med2 tripped me up, because I kept thinking this referred to MED_SRC_2.2.2 in the tarball... but it is a separate package. Once I realized that, it was still a pain to find it. It's on the Code_Aster website (french), download here: http://www.code-aster.org/telechargement/tele_prod.php?prod=med&liste=all
Mon, 06/13/2005 - 09:49
Hi Mark!
i have a problem in configuring the sample program available in /opencascade/samples/standard/qt/configure. i tried to reset the variable based on my setting, it doesn't work! and i used the command --with-cascade-includes=/opencasecade/ros/inc, but it doesn't work too.
I am getting the configure: error : CasCade(libraries) not found. please check your installation.
pls help me to solve this
Mon, 06/13/2005 - 10:48
I don't know what's wrong, I get the same error. I had to dig through the configure script a LOT to find out what was wrong with salome. It looks like it's finding the includes, but not the libraries (The possible errors listed in the configure script include one for includes only, one for libraries only, and one for both includes and libraries.) Maybe try using --with-cascade-libraries=/path/to/occ/libs
I suggest copying the configure file and hacking on it... for example, after line 1945 of configure, add a line `echo $ac_compile` to see the compiler command used. Another thing to do is add a command to copy the test file being compiled BEFORE it gets deleted, both so you can look at it, and so you can try compiling it to see what errors gcc spits out.
Good luck.
Mark