<html>
<body>
<font size=3>I tried completely removing both the omniORBpy-3.0 and
omniORB-4.1 directory trees, then rebuilding omniORB-4.0.7 and
omniORBpy-2.7 from the tar file. The installation for omniORB-4.0.7 went
fine, and the echo examples work, but I still get the AttributeError
message when I try to make the omniORBpy files.&nbsp; There is something
still pointing to the 3.0 installation, what is it?&nbsp; <br><br>
Would it be a good idea to add an 'uninstall' option to the
Makefile?<br><br>
Tom Meyer<br><br>
At 02:22 AM 11/7/2006, Duncan Grisby wrote:<br>
<blockquote type=cite class=cite cite="">On Monday 6 November, W T Meyer
wrote:<br><br>
&gt; I'm trying to install omniORBpy-2.7 on a new system running
Scientific<br>
&gt; Linux 3.0.7 on a Dell computr with an Intel processor.&nbsp; I've
already<br>
&gt; installed omniORB-4.07, and the echo example works. After
extracting<br>
&gt; omniORBpy-2.7 and running the configure script, running 'make'
works<br>
&gt; fine until it enters the COS directory, where it fails. Any help
is<br>
&gt; appreciated.<br><br>
[...]<br>
&gt; AttributeError: 'module' object has no attribute
'containsValueType'<br><br>
You have somehow picked up the python back-end from omniORBpy 3.0,
and<br>
it's running against the omniidl from omniORB 4.0.7. The two don't
work<br>
together. Make sure you're using consistent versions of omniORB and<br>
omniORBpy and it should be fine.<br><br>
Cheers,<br><br>
Duncan.<br><br>
-- <br>
&nbsp;-- Duncan Grisby&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--<br>
&nbsp; -- duncan@grisby.org&nbsp;&nbsp;&nbsp;&nbsp; --<br>
&nbsp;&nbsp; --
<a href="http://www.grisby.org/" eudora="autourl">
http://www.grisby.org</a> --</font></blockquote></body>
<br>
</html>