Re: [Pkg-corba-devel] OpenCASCADE and Salomé
Dear Adam, Thomas, and list, I try to compile Salome on my system (32-bit Intel Core2, Kubuntu 7.10 (gutsy)) but get the same error as Thomas (ld cannot find -lSMESHimpl). How is the workaround? As it seemes, you proceeded further. Thanks and best regards, Dan Adam C Powell IV wrote: I am willing to help you with this, and tried to compile Salomé on my system but got blocked before the step you reached. When compiling NETGENPlugin, I get: /usr/bin/ld: cannot find -lSMESHimpl I have regenerated and installed OpenCASCADE 6.2.0-7 and recompiled hdf5 1.6.5-5.2 with your patch for OpenMPI on top of it. Do you know what's wrong in my local installation? Wow, thanks for putting in the hard work to help with this!! Actually, if you look at your log, it failed well before getting to that point, so it didn't build the SMESH library. I need to get the build to actually stop when it fails during the for ... $(MAKE) ... done loop in rules... Thank you again, -Adam -- View this message in context: http://www.nabble.com/OpenCASCADE-and-Salom%C3%A9-tp14678225p16419772.html Sent from the debian-science mailing list archive at Nabble.com.
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
Greetings, The problem is much earlier, in the GUI module: sip4 4.7.4 is failing. See Debian bug 469850 and http://www.riverbankcomputing.com/pipermail/pyqt/2008-March/01.html I have some time to work on it this evening to prepare a small test case for that list. From there, thanks to Thomas' help, it should be straightforward to complete the omniORB 4.1.x port. -Adam On Tue, 2008-04-01 at 10:53 -0700, Darko P. wrote: Dear Adam, Thomas, and list, I try to compile Salome on my system (32-bit Intel Core2, Kubuntu 7.10 (gutsy)) but get the same error as Thomas (ld cannot find -lSMESHimpl). How is the workaround? As it seemes, you proceeded further. Thanks and best regards, Dan Adam C Powell IV wrote: I am willing to help you with this, and tried to compile Salomé on my system but got blocked before the step you reached. When compiling NETGENPlugin, I get: /usr/bin/ld: cannot find -lSMESHimpl I have regenerated and installed OpenCASCADE 6.2.0-7 and recompiled hdf5 1.6.5-5.2 with your patch for OpenMPI on top of it. Do you know what's wrong in my local installation? Wow, thanks for putting in the hard work to help with this!! Actually, if you look at your log, it failed well before getting to that point, so it didn't build the SMESH library. I need to get the build to actually stop when it fails during the for ... $(MAKE) ... done loop in rules... Thank you again, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Thu, 2008-03-06 at 09:28 -0500, Adam C Powell IV wrote: Okay, I've made it build as far as I can, into a number of similar corrections in the SUPERV module. However, there's a sip/Qt error in the GUI module: /usr/bin/sip -t WS_X11 -t Qt_3_3_8b -x Qt_STYLE_INTERLACE -x Qt_STYLE_WINDOWSXP -x Qt_ASSISTANTCLIENT -s .cc -c . -I /usr/share/sip/qt/qt SALOME_PYQT_GUI.sip sip: QPixmap has not been defined I added the following Build-Depends: python-qt-dev sip4 python-sip4-dev libvtk5-qt3-dev . I don't have time to finish this just now, will get back to it and post an updated patch/package later today. Just put -6 at the usual place http://lyre.mit.edu/public_html/salome/ and filed bug 496850 against sip4 (after confirming it wouldn't build on my testing machine as it used to, so it's not a build-dep problem). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Fri, 2008-03-07 at 09:08 -0500, Adam C Powell IV wrote: On Thu, 2008-03-06 at 09:28 -0500, Adam C Powell IV wrote: Okay, I've made it build as far as I can, into a number of similar corrections in the SUPERV module. However, there's a sip/Qt error in the GUI module: /usr/bin/sip -t WS_X11 -t Qt_3_3_8b -x Qt_STYLE_INTERLACE -x Qt_STYLE_WINDOWSXP -x Qt_ASSISTANTCLIENT -s .cc -c . -I /usr/share/sip/qt/qt SALOME_PYQT_GUI.sip sip: QPixmap has not been defined I added the following Build-Depends: python-qt-dev sip4 python-sip4-dev libvtk5-qt3-dev . I don't have time to finish this just now, will get back to it and post an updated patch/package later today. Just put -6 at the usual place http://lyre.mit.edu/public_html/salome/ D'oh! http://lyre.mit.edu/~powell/salome/ -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Wed, 2008-03-05 at 23:29 +0100, Thomas Girard wrote: Hello Adam, Le mercredi 05 mars 2008 à 07:34 -0500, Adam C Powell IV a écrit : I'm not getting this error... I don't know why you would have seen that MPI error, I'd patched openmpi before but upgrading to 1.2.5-2 undid my patch and it works for me. I reapplied my patch to hdf5 1.6.5-5.2 (minus the changelog bit) and retried, and didn't see your error; Okay, got it: /usr/lib/libmpi++.so is an aternative registered with liblam++.so (which was needed for hdf5 compilation). Maybe salome should build-conflict with lam4-dev? Hmmm... removing lam-dev makes /usr/lib/libmpi++.so an alternative symlink to libpmpich++.so.1.0, and not to libmpi_cxx.so.0.0.0. It seems only libmpi_cxx.so works: I have forced the symlink and the link error disappeared. Ah right. update-alternatives --config mpi should let you select OpenMPI for all of those links. But to be on the safe side, I've added Build-Conflicts against lam4-dev and all of the mpich-dev variants. the error I'm getting now is a bit further down in TestContainer: 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=\/bin/false\ -DSCP=\/bin/false\ -I. -I./../Basics -I./../SALOMELocalTrace -I./../NamingService -I./../Utils -I./../Registry -I./../Notification -I./../ResourcesManager -I./../Container -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 libSalomeTestComponentEngine_la-SALOME_TestComponent_i.lo -MD -MP -MF .deps/libSalomeTestComponentEngine_la-SALOME_TestComponent_i.Tpo -c SALOME_TestComponent_i.cxx -fPIC -DPIC -o .libs/libSalomeTestComponentEngine_la-SALOME_TestComponent_i.o SALOME_TestComponent_i.cxx: In constructor ‘Engines_TestComponent_i::Engines_TestComponent_i(CORBA::ORB*, PortableServer::POA*, PortableServer::ObjectId*, const char*, const char*)’: SALOME_TestComponent_i.cxx:47: error: ‘pd_refCount’ was not declared in this scope SALOME_TestComponent_i.cxx: In member function ‘virtual char* Engines_TestComponent_i::Coucou(CORBA::Long)’: SALOME_TestComponent_i.cxx:63: error: ‘pd_refCount’ was not declared in this scope SALOME_TestComponent_i.cxx: In member function ‘virtual void Engines_TestComponent_i::Setenv()’: SALOME_TestComponent_i.cxx:85: warning: unused variable ‘ret’ SALOME_TestComponent_i.cxx:70: warning: unused variable ‘overwrite’ make[3]: *** [libSalomeTestComponentEngine_la-SALOME_TestComponent_i.lo] Error 1 make[3]: Leaving directory `/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/TestContainer' Any ideas on this? yes: pd_refCount, which was defined as the reference count in RefCountServantBase is now named _pd_refCount in ServantBase. That's the only occurrence of pd_refCount in Salomé sources. Thank you! My box is still compiling Salomé... Okay, I've made it build as far as I can, into a number of similar corrections in the SUPERV module. However, there's a sip/Qt error in the GUI module: /usr/bin/sip -t WS_X11 -t Qt_3_3_8b -x Qt_STYLE_INTERLACE -x Qt_STYLE_WINDOWSXP -x Qt_ASSISTANTCLIENT -s .cc -c . -I /usr/share/sip/qt/qt SALOME_PYQT_GUI.sip sip: QPixmap has not been defined I added the following Build-Depends: python-qt-dev sip4 python-sip4-dev libvtk5-qt3-dev . I don't have time to finish this just now, will get back to it and post an updated patch/package later today. Thanks again, this is incredibly helpful! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On 6 March 2008 at 09:28, Adam C Powell IV wrote: | On Wed, 2008-03-05 at 23:29 +0100, Thomas Girard wrote: | Hello Adam, | | Le mercredi 05 mars 2008 à 07:34 -0500, Adam C Powell IV a écrit : | I'm not getting this error... I don't know why you would have seen that | MPI error, I'd patched openmpi before but upgrading to 1.2.5-2 undid my | patch and it works for me. I reapplied my patch to hdf5 1.6.5-5.2 | (minus the changelog bit) and retried, and didn't see your error; | | Okay, got it: /usr/lib/libmpi++.so is an aternative registered with | liblam++.so (which was needed for hdf5 compilation). Maybe salome should | build-conflict with lam4-dev? | | Hmmm... removing lam-dev makes /usr/lib/libmpi++.so an alternative | symlink to libpmpich++.so.1.0, and not to libmpi_cxx.so.0.0.0. It seems | only libmpi_cxx.so works: I have forced the symlink and the link error | disappeared. | | Ah right. update-alternatives --config mpi should let you select | OpenMPI for all of those links. But to be on the safe side, I've added | Build-Conflicts against lam4-dev and all of the mpich-dev variants. The Open MPI package recently fixed an oversight with respect to the C++ library. Could you try the most recent one, ie 1.2.5-2, and see if that works out of the box ? It should, we think we now have most things ironed out with respect to the stand C library. Thanks, Dirk -- Three out of two people have difficulties with fractions.
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Thu, 2008-03-06 at 09:19 -0600, Dirk Eddelbuettel wrote: On 6 March 2008 at 09:28, Adam C Powell IV wrote: | On Wed, 2008-03-05 at 23:29 +0100, Thomas Girard wrote: | Hello Adam, | | Le mercredi 05 mars 2008 à 07:34 -0500, Adam C Powell IV a écrit : | I'm not getting this error... I don't know why you would have seen that | MPI error, I'd patched openmpi before but upgrading to 1.2.5-2 undid my | patch and it works for me. I reapplied my patch to hdf5 1.6.5-5.2 | (minus the changelog bit) and retried, and didn't see your error; | | Okay, got it: /usr/lib/libmpi++.so is an aternative registered with | liblam++.so (which was needed for hdf5 compilation). Maybe salome should | build-conflict with lam4-dev? | | Hmmm... removing lam-dev makes /usr/lib/libmpi++.so an alternative | symlink to libpmpich++.so.1.0, and not to libmpi_cxx.so.0.0.0. It seems | only libmpi_cxx.so works: I have forced the symlink and the link error | disappeared. | | Ah right. update-alternatives --config mpi should let you select | OpenMPI for all of those links. But to be on the safe side, I've added | Build-Conflicts against lam4-dev and all of the mpich-dev variants. The Open MPI package recently fixed an oversight with respect to the C++ library. Could you try the most recent one, ie 1.2.5-2, and see if that works out of the box ? It should, we think we now have most things ironed out with respect to the stand C library. Thanks Dirk; I think the issue was that with other MPI implementations also installed, the alternatives symlinks pointed to them, but my package tells Salomé to look in /usr/lib/openmpi/include for headers. So it was getting mpi.h from OpenMPI and failing to link with lam and mpich. Not a problem in general. We're both using 1.2.5-2 in unstable. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
Wow, thank you again for your work on this! On Mon, 2008-03-03 at 15:48 +0100, Thomas Girard wrote: On Mon, Mar 03, 2008 at 02:24:51PM +0100, Thomas Girard wrote: I'm currently trying to fully compile Salomé and will report to you next failures. I get the following error: /usr/lib/openmpi/include/openmpi/ompi/mpi/cxx/op_inln.h:122: undefined reference to `ompi_mpi_cxx_op_intercept' when compiling KERNEL_SRC_3.2.6/src/Container. Any suggestion? I'm not getting this error... I don't know why you would have seen that MPI error, I'd patched openmpi before but upgrading to 1.2.5-2 undid my patch and it works for me. I reapplied my patch to hdf5 1.6.5-5.2 (minus the changelog bit) and retried, and didn't see your error; the error I'm getting now is a bit further down in TestContainer: 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=\/bin/false\ -DSCP=\/bin/false\ -I. -I./../Basics -I./../SALOMELocalTrace -I./../NamingService -I./../Utils -I./../Registry -I./../Notification -I./../ResourcesManager -I./../Container -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 libSalomeTestComponentEngine_la-SALOME_TestComponent_i.lo -MD -MP -MF .deps/libSalomeTestComponentEngine_la-SALOME_TestComponent_i.Tpo -c SALOME_TestComponent_i.cxx -fPIC -DPIC -o .libs/libSalomeTestComponentEngine_la-SALOME_TestComponent_i.o SALOME_TestComponent_i.cxx: In constructor ‘Engines_TestComponent_i::Engines_TestComponent_i(CORBA::ORB*, PortableServer::POA*, PortableServer::ObjectId*, const char*, const char*)’: SALOME_TestComponent_i.cxx:47: error: ‘pd_refCount’ was not declared in this scope SALOME_TestComponent_i.cxx: In member function ‘virtual char* Engines_TestComponent_i::Coucou(CORBA::Long)’: SALOME_TestComponent_i.cxx:63: error: ‘pd_refCount’ was not declared in this scope SALOME_TestComponent_i.cxx: In member function ‘virtual void Engines_TestComponent_i::Setenv()’: SALOME_TestComponent_i.cxx:85: warning: unused variable ‘ret’ SALOME_TestComponent_i.cxx:70: warning: unused variable ‘overwrite’ make[3]: *** [libSalomeTestComponentEngine_la-SALOME_TestComponent_i.lo] Error 1 make[3]: Leaving directory `/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/TestContainer' Any ideas on this? Thanks again! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
Hello Adam,
Le mercredi 05 mars 2008 à 07:34 -0500, Adam C Powell IV a écrit :
I'm not getting this error... I don't know why you would have seen that
MPI error, I'd patched openmpi before but upgrading to 1.2.5-2 undid my
patch and it works for me. I reapplied my patch to hdf5 1.6.5-5.2
(minus the changelog bit) and retried, and didn't see your error;
Okay, got it: /usr/lib/libmpi++.so is an aternative registered with
liblam++.so (which was needed for hdf5 compilation). Maybe salome should
build-conflict with lam4-dev?
Hmmm... removing lam-dev makes /usr/lib/libmpi++.so an alternative
symlink to libpmpich++.so.1.0, and not to libmpi_cxx.so.0.0.0. It seems
only libmpi_cxx.so works: I have forced the symlink and the link error
disappeared.
the error I'm getting now is a bit further down in TestContainer:
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=\/bin/false\ -DSCP=\/bin/false\ -I. -I./../Basics
-I./../SALOMELocalTrace -I./../NamingService -I./../Utils -I./../Registry
-I./../Notification -I./../ResourcesManager -I./../Container
-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
libSalomeTestComponentEngine_la-SALOME_TestComponent_i.lo -MD -MP -MF
.deps/libSalomeTestComponentEngine_la-SALOME_TestComponent_i.Tpo -c
SALOME_TestComponent_i.cxx -fPIC -DPIC -o
.libs/libSalomeTestComponentEngine_la-SALOME_TestComponent_i.o
SALOME_TestComponent_i.cxx: In constructor
‘Engines_TestComponent_i::Engines_TestComponent_i(CORBA::ORB*,
PortableServer::POA*, PortableServer::ObjectId*, const char*, const char*)’:
SALOME_TestComponent_i.cxx:47: error: ‘pd_refCount’ was not declared in this
scope
SALOME_TestComponent_i.cxx: In member function ‘virtual char*
Engines_TestComponent_i::Coucou(CORBA::Long)’:
SALOME_TestComponent_i.cxx:63: error: ‘pd_refCount’ was not declared in this
scope
SALOME_TestComponent_i.cxx: In member function ‘virtual void
Engines_TestComponent_i::Setenv()’:
SALOME_TestComponent_i.cxx:85: warning: unused variable ‘ret’
SALOME_TestComponent_i.cxx:70: warning: unused variable ‘overwrite’
make[3]: *** [libSalomeTestComponentEngine_la-SALOME_TestComponent_i.lo]
Error 1
make[3]: Leaving directory
`/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/TestContainer'
Any ideas on this?
yes: pd_refCount, which was defined as the reference count in
RefCountServantBase is now named _pd_refCount in ServantBase. That's the
only occurrence of pd_refCount in Salomé sources.
My box is still compiling Salomé...
Regards,
Thomas
--- salome-3.2.6.orig/KERNEL_SRC_3.2.6/src/TestContainer/SALOME_TestComponent_i.cxx
+++ salome-3.2.6/KERNEL_SRC_3.2.6/src/TestContainer/SALOME_TestComponent_i.cxx
@@ -44,7 +44,7 @@
MESSAGE(activate object);
_thisObj = this ;
_id = _poa-activate_object(_thisObj);
- SCRUTE(pd_refCount);
+ SCRUTE(_pd_refCount);
}
Engines_TestComponent_i::Engines_TestComponent_i()
@@ -60,7 +60,7 @@
{
char s[100];
sprintf(s, TestComponent_i : L = %ld, (long) L);
- SCRUTE(pd_refCount);
+ SCRUTE(_pd_refCount);
return CORBA::string_dup(s);
}
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
Hello Thomas,
On Fri, 2008-02-29 at 09:23 +0100, Thomas Girard wrote:
Hello Adam,
On Wed, Feb 27, 2008 at 12:29:11PM -0500, Adam C Powell IV wrote:
So the following pipeline (modifying Salomé files, beware!), run from
Salomé toplevel directory, should work:
find -type f -print0 | xargs -0 grep RefCountServantBase | cut -d: -f1 |
sort | uniq | xargs sed -i -e 's/RefCountServantBase/ServantBase/g'
Could you please try to compile this modified Salomé with omniORB 4.1 from
unstable, and report if it succeeds?
Thanks for your help! Unfortunately, it did not work. :-(
Okay, my mistake. In fact for inheritance there's no need to add
PortableServer::ServantBase, as it's already inherited from by the
POA_XXX generated skeleton.
So I think what needs to be done for porting Salomé to omniORB 4.1 is:
* when a class declaration inherits from POA_XXX and
RefCountServantBase, remove RefCountServantBase.
* calls to RefCountServantBase::{_add_ref(),_remove_ref()} have to be
replaced with ServantBase::{_add_ref(),_remove_ref()}.
Okay, did that, and it gets past the last error. Great!
Now there's a new one, six no match for 'operator=' errors, each
followed by over 300 CORBA-related candidates... I don't quite see how
to do this; is it apparent to an omniORB expert?
I've posted the new -5 .diff.gz (with patch at the top) and .dsc, the
(truncated) log (search for error:), and the preprocessor output
NOTIFICATION_Consumer.E at http://lyre.mit.edu/~powell/salome/
I am willing to help you with this, and tried to compile Salomé on my
system but got blocked before the step you reached. When compiling
NETGENPlugin, I get:
/usr/bin/ld: cannot find -lSMESHimpl
I have regenerated and installed OpenCASCADE 6.2.0-7 and recompiled
hdf5 1.6.5-5.2 with your patch for OpenMPI on top of it.
Do you know what's wrong in my local installation?
Wow, thanks for putting in the hard work to help with this!!
Actually, if you look at your log, it failed well before getting to that
point, so it didn't build the SMESH library. I need to get the build to
actually stop when it fails during the for ... $(MAKE) ... done loop
in rules...
Thank you again,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
On Mon, 2008-02-25 at 15:36 +0100, Thomas Girard wrote:
On Mon, Feb 25, 2008 at 03:23:31PM +0100, Thomas Girard wrote:
From a first sight, it seems to me that replacing:
RefCountServantBase
with:
ServantBase
in Salomé files should be enough.
So the following pipeline (modifying Salomé files, beware!), run from
Salomé toplevel directory, should work:
find -type f -print0 | xargs -0 grep RefCountServantBase | cut -d: -f1 |
sort | uniq | xargs sed -i -e 's/RefCountServantBase/ServantBase/g'
Could you please try to compile this modified Salomé with omniORB 4.1 from
unstable, and report if it succeeds?
Thanks for your help! Unfortunately, it did not work. :-(
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=\/bin/false\ -DSCP=\/bin/false\ -I.
-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
libSalomeLoggerServer_la-SALOME_Logger_Server.lo -MD -MP -MF
.deps/libSalomeLoggerServer_la-SALOME_Logger_Server.Tpo -c
SALOME_Logger_Server.cxx -fPIC -DPIC -o
.libs/libSalomeLoggerServer_la-SALOME_Logger_Server.o
In file included from SALOME_Logger_Server.cxx:12:
SALOME_Logger_Server.hxx:26: warning: direct base ‘PortableServer::ServantBase’
inaccessible in ‘Logger’ due to ambiguity
SALOME_Logger_Server.hxx:26: error: no unique final overrider for ‘virtual
void* omniServant::_downcast()’ in ‘Logger’
SALOME_Logger_Server.hxx:26: error: no unique final overrider for ‘virtual
omniObjRef* omniServant::_do_get_interface()’ in ‘Logger’
SALOME_Logger_Server.hxx:26: error: no unique final overrider for ‘virtual void
omniServant::_add_ref()’ in ‘Logger’
SALOME_Logger_Server.hxx:26: error: no unique final overrider for ‘virtual void
omniServant::_remove_ref()’ in ‘Logger’
make[3]: *** [libSalomeLoggerServer_la-SALOME_Logger_Server.lo] Error 1
I'm attaching the .cxx and .hxx files.
This is the first fixed file the build encountered. If you have any
ideas on how to proceed, I'm all ears -- and have time to work on it.
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
// SALOME Logger : CORBA server managing trace output
//
// Copyright (C) 2003 CEA/DEN, EDF RD
//
// See http://www.salome-platform.org/ or email : [EMAIL PROTECTED]
//
// File : SALOME_Logger_Server.cxx
// Author : Vasily Rusyaev
// Module : SALOME
#include iostream
#include SALOME_Logger_Server.hxx
#include SALOMEconfig.h
#include sys/types.h
#ifndef __WIN32__
# include unistd.h
#endif
#ifdef WNT
#include omnithread/pthread_nt.h
#endif
omni_mutex Logger::myLock;
/
// Construction/Destruction
//
Logger::Logger()
{
m_putIntoFile = false;
}
Logger::Logger(const char *filename)
{
// m_outputFile.open( filename, ios::out | ios::trunc , filebuf::openprot);
m_outputFile.open( filename, std::ios::out | std::ios::trunc);
if (m_outputFile.is_open())
m_putIntoFile = true;
else
m_putIntoFile = false;
}
Logger::~Logger()
{
if (m_putIntoFile)
m_outputFile.close();
}
void Logger::putMessage(const char* message)
{
myLock.lock();
if (m_putIntoFile)
m_outputFile message std::flush;
else
std::cout message;
myLock.unlock();
}
void Logger::ping()
{
//cout Logger::ping() pid getpid()endl;
}
// SALOME Logger : CORBA server managing trace output
//
// Copyright (C) 2003 CEA/DEN, EDF RD
//
// See http://www.salome-platform.org/ or email : [EMAIL PROTECTED]
//
// File : SALOME_Logger_Server.hxx
// Author : Vasily Rusyaev
// Module : SALOME
#if !defined SALOME_Logger_Server_include
#define SALOME_Logger_Server_include
#ifndef WNT
#include fstream.h
#else
#include fstream
#include iosfwd
#endif
#include omnithread.h
#include Logger.hh
class Logger :
public POA_SALOME_Logger::Logger,
public PortableServer::ServantBase
{
public:
//constructor w/o parameters
//all messages will be put into terminal via
Re: [Pkg-corba-devel] OpenCASCADE and Salomé
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/
