omniORB 4.0.3 and omniORBpy 2.3 available

[Duncan Grisby]

omniORB 4.0.3 and omniORBpy 2.3 are now available. They are bug fix
releases. Many thanks to all the people who have contributed bug fixes
and features.

omniORB is a robust, high performance CORBA implementation for C++.
omniORBpy is a version for Python. They are open source, available
under the terms of the GNU LGPL.

As always, the releases can be downloaded from SourceForge in source
and Windows binary formats:

http://sourceforge.net/project/showf...group_id=51138

Enjoy.

Duncan.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[RCS]

I downloaded both the omniORB-4.0.3.tar.gz and the
omniORB-4.0.3-x86_win32.zip files, and tried to build the libs and DLL
(using Visual Studio 7).

The platform I chose was
platform = x86_nt_4.0_vs_7

In both cases I got a ton of unsresolved externals (632 of them).

When I build OmniORB-4.0.2 I used the exact same procedure, using the same
compiler, and it went fine.

What is missing from the 4.0.3 distribution?

Regards,
RCS

"Duncan Grisby" <du*********@grisby.org> skrev i melding
news:46***************************@nf2.news-service.com...

omniORB 4.0.3 and omniORBpy 2.3 are now available. They are bug fix
releases. Many thanks to all the people who have contributed bug fixes
and features.

omniORB is a robust, high performance CORBA implementation for C++.
omniORBpy is a version for Python. They are open source, available
under the terms of the GNU LGPL.

As always, the releases can be downloaded from SourceForge in source
and Windows binary formats:

http://sourceforge.net/project/showf...group_id=51138

Enjoy.

Duncan.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[Duncan Grisby]

In article <hH******************@news4.e.nsc.no>, RCS <rc****@online.no> wrote:

I downloaded both the omniORB-4.0.3.tar.gz and the
omniORB-4.0.3-x86_win32.zip files, and tried to build the libs and DLL
(using Visual Studio 7).

The platform I chose was
platform = x86_nt_4.0_vs_7

In both cases I got a ton of unsresolved externals (632 of them).

When I build OmniORB-4.0.2 I used the exact same procedure, using the same
compiler, and it went fine.

First, as another poster suggested, make sure you have nothing to do
with omniORB on your path before you try the new compile. If that
still fails, please subscribe to the omniORB mailing list, and post
details of the missing symbols to there.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --

[RCS]

"Duncan Grisby" <du*********@grisby.org> skrev i melding
news:15***************************@nf2.news-service.com...

First, as another poster suggested, make sure you have nothing to do
with omniORB on your path before you try the new compile.
I did that, and tough luck, the same unresolved 632 external symbols.
If that still fails, please subscribe to the omniORB mailing list, and post details of the missing symbols to there.

Well, I have tried earlier to post to the mailing lists, but what I always
get as a response is this:

"Your mail to 'omniORB-list' with the subject
<my message subject>
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list"

and some time later I recieve an email that the message was not accepted due
to my not being a member, even if I have registered as a member (and recieve
mails every day from the list).

So I excpect it this time also not to pass through to the members of the
mailing list.

Anyway, here are some of the unresolved external symbols (from among those I
could capture in the DOS window):

* CosNaming::NamingContext::CannotProceed::insertToA nyFn ... referenced in
function CosNaming::NamingContext::CannotProceed:: scalar deleting
destructor
* CosNaming::NamingContext::CannotProceed::_NP_repoI d ... referenced in
function CosNaming::NamingContext::CannotProceed::CannotPro ceed
* CosNaming::NamingContext::NotFound::_NP_typeId ...
* CosNaming::NamingContextExt_Helper::release ...
* CosNaming::NamingContext_Helper::release
* CosNaming::NamingContext::AlreadyBound::~AlreadyBo und
* CosNaming::NamingContext::NotEmpty::_NP_marshal
* CosNaming::NamingContext::InvalidName::_NP_repoId
Regards
RCS

[Duncan Grisby]

In article <EM******************@news4.e.nsc.no>, RCS <rc****@online.no> wrote:

First, as another poster suggested, make sure you have nothing to do
with omniORB on your path before you try the new compile.

I did that, and tough luck, the same unresolved 632 external symbols.

Just to check, are you using the source tarball, or the pre-compiled
Win32 binary .zip file? You should not use the binary .zip since that
is compiled with VC++ 6, and will conflict with VC++ 7.

If that still fails, please subscribe to the omniORB mailing list, and
post details of the missing symbols to there.

Well, I have tried earlier to post to the mailing lists, but what I always
get as a response is this:

"Your mail to 'omniORB-list' with the subject
<my message subject>
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list"

and some time later I recieve an email that the message was not accepted due
to my not being a member, even if I have registered as a member (and recieve
mails every day from the list).

I see you have sorted it out now, but for anyone else, the cause of
this is always that you have subscribed from one email address but are
trying to post from another address.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- du****@grisby.org --
-- http://www.grisby.org --