[Pkg-corba-devel] OpenCASCADE and Salomé
Adam C Powell IV
hazelsct at debian.org
Sun Feb 24 12:49:21 UTC 2008
On Sat, 2008-02-23 at 10:37 +0100, Thomas Girard wrote:
> Le mercredi 09 janvier 2008 à 00:12 -0500, Adam C Powell IV a écrit :
> > Meanwhile, there's an earlier build error in Salomé on unstable, so it
> > doesn't even get to the _STL:: vs. std:: issue. It dies when trying to
> > compile the first _i file:
> > g++ "-DPACKAGE_NAME=\"Salome2 Project\"" -DPACKAGE_TARNAME=\"salome\" -DPACKAGE_VERSION=\"3.2.5\" "-DPACKAGE_STRING=\"Salome2 Project 3.2.5\"" -DPACKAGE_BUGREPORT=\"gboulant at CS\" -DPACKAGE=\"salome\" -DVERSION=\"3.2.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBDL=1 -DHAVE_LIBRT=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES= -DHAVE_PTHREAD=1 -D__x86__=1 -D__linux__=1 -D__OSVERSION__=1 -DOMNIORB=1 -DCORBA_HAVE_POA=1 -DCORBA_ORB_INIT_HAVE_3_ARGS=1 -DCORBA_ORB_INIT_THIRD_ARG=\"omniORB\" -DRM=\"/bin/rm\" -DSH=\"/bin/sh\" -DCP=\"/bin/cp\" -DRSH=\"/usr/bin/rsh\" -DRCP=\"/usr/bin/rcp\" -DSSH=\"/usr/bin/ssh\" -DSCP=\"/usr/bin/scp\" -I. -I. -I./../Basics -I./../SALOMELocalTrace -I../../salome_adm/unix -I../../idl -DOMNIORB_VERSION=4 -D__x86__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -DHAVE_MPI2 -DHAVE_SOCKET -m64 -D_OCC64 -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -pthread -MT libSalomeGenericObj_la-SALOME_GenericObj_i.lo -MD -MP -MF .deps/libSalomeGenericObj_la-SALOME_GenericObj_i.Tpo -c SALOME_GenericObj_i.cc -fPIC -DPIC -o .libs/libSalomeGenericObj_la-SALOME_GenericObj_i.o
> > SALOME_GenericObj_i.cc: In constructor 'SALOME::GenericObj_i::GenericObj_i(PortableServer::POA*)':
> > SALOME_GenericObj_i.cc:45: error: '_default_POA' is not a member of 'PortableServer::RefCountServantBase'
> > make: *** [libSalomeGenericObj_la-SALOME_GenericObj_i.lo] Error 1
> > make: Leaving directory `/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/GenericObj'
> > I've attached the .idl and _i.cc files. Could it be possible that
> > omniorb4 changed its IDL format and/or implementation interface between
> > 4.0.6 and 4.1.1? (It still compiles just fine in testing, which has
> > 4.0.6.) That doesn't seem right, those things should be frozen in the
> > CORBA standard, right? What needs to change to work with 4.1.1?
> I forgot to answer that email: did you manage to compile Salomé with
> STLport5.1? And omniORB 4.1? If you need a hand please let me know. We
> are currently tring to fix omniORB 4.1 FTBFS on arm, and when we're done
> omniORB 4.0 will disappear from testing.
No. So I dropped STLport from OpenCASCADE (which Salomé depends on; C++
namespaces are a PITA!!), and used omniORB 4.0.x, and it works just
fine. (Well, I had a lot of other problems to overcome, from HDF5/MPI
to a VTK4->5 port to some very sloppy upstream build practices, but it
does work now, and beautifully.)
I've made a couple of attempts to contact upstream to inquire about
plans for a port to omniORB 4.1, but haven't heard back yet. It seems
like quite a bit of work from what I can tell, as some of the
assumptions have changed; in any case, far beyond what I have time for.
I was planning to write to pkg-corba-devel either when I heard from
upstream or some time passed, to propose creating new omniorb4.0 and
python-omniorb2.6 packages to use for Salomé and Code_Aster (a finite
element program which links well with it). I would be happy to maintain
these, upgrade to 4.0.7, etc., and to put them in your alioth repository
as a branch or as separate packages, whatever you think best.
What do you think?
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
More information about the Pkg-corba-devel