On Sat, 2008-02-23 at 10:37 +0100, Thomas Girard wrote: > Hello, > > 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=\"[EMAIL PROTECTED]" -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[2]: *** [libSalomeGenericObj_la-SALOME_GenericObj_i.lo] Error 1 > > make[2]: 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? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
