[omniORB] RE: OmniORB 3.05 on cygwin
Ali Reza
A.Reza at zensar.com
Fri Dec 5 17:41:51 GMT 2003
Duncan has answered this question sometime back. I'm attaching the same for your reference.
On Thursday 30 October, "Ali Reza" wrote:
> > omniORB doesn't work with cygwin. You have to use MSVC.
>
> Is there any specific reason why ?
The last time someone tried to port to cygwin, it turned out that the
threading support was not complete enough for it to work. It may be
better now.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com]On Behalf Of
omniorb-list-request at omniorb-support.com
Sent: Friday, December 05, 2003 5:30 PM
To: omniorb-list at omniorb-support.com
Subject: omniORB-list Digest, Vol 8, Issue 8
Send omniORB-list mailing list submissions to
omniorb-list at omniorb-support.com
To subscribe or unsubscribe via the World Wide Web, visit
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
or, via email, send a message with subject or body 'help' to
omniorb-list-request at omniorb-support.com
You can reach the person managing the list at
omniorb-list-owner at omniorb-support.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of omniORB-list digest..."
Today's Topics:
1. Omniorb 3.05 on cygwin (Jiva DeVoe)
2. omniORBpy 2.3 and Mac OSX (Zachery Corbiere)
3. Re: omniORBpy 2.3 and Mac OSX (Zachery Corbiere)
4. constructing an IOR (Cameron Rochester)
5. OmniNotify2.0beta for Solaris 5.8 64bits (FredP)
6. FW: [omniORB] deleting active servants -- repost (P?ncz?l Levente)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Dec 2003 12:05:38 -0700
From: Jiva DeVoe <jiva at ixiacom.com>
Subject: [omniORB] Omniorb 3.05 on cygwin
To: <omniorb-list at omniorb-support.com>
Message-ID: <BBF4D392.3A31%jiva at ixiacom.com>
Content-Type: text/plain; charset="US-ASCII"
Greetings,
I'm trying to compile omniORB 3.0.5 on Windows XP using Cygwin.
Unfortunately, I'm getting a series of "undefined references". The
undefined references all seem to refer to _Py_... Type of things so I'm
assuming that they are Python related. I'm using the Cygwin supplied Python
installation, and have installed the sources. My Python version is 2.3.2.
Can anyone tell me what I have wrong here?
Here's some of the compiler output...
idlpython.o(.text+0x1ab):idlpython.cc: undefined reference to `_PyErr_Print'
idlpython.o(.text+0x1de):idlpython.cc: undefined reference to `_PyErr_Print'
idlpython.o(.text+0x23d):idlpython.cc: undefined reference to
`__Unwind_Resume'
------------------------------
Message: 2
Date: Thu, 4 Dec 2003 22:21:51 -0600
From: Zachery Corbiere <zcorb at fluidarch.com>
Subject: [omniORB] omniORBpy 2.3 and Mac OSX
To: omniorb-list at omniorb-support.com
Message-ID: <8D13065C-26DA-11D8-8DBF-000A95C729A2 at fluidarch.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
First, thanks for all the hard work that's obviously gone into
omniORB/omniORBpy! I've been using omniORBpy on Linux and Windows for
about a year and a half with great results.
Now I'm attempting to use it on Mac OSX. I run the ./configure, make,
make install for both omniORB-4.0.3 and omniORBpy 2.3 and everything
goes without a hitch. Furthermore, I've compiled and successfully run
the C++ echo examples. This is all on version 10.3.1 with the dev
tools that come with 10.3.
When I attempt to run omniORBpy, though, I get the following error:
>>> args=['-ORBInitRef', 'NameService=corbaname::localhost']
>>> from omniORB import CORBA
*** malloc[21519]: error for object 0x311240: Double free
>>> orb=CORBA.ORB_init(args)
omniORB: ORB_init failed: unknown option (-ORBInitRef) in -ORB arguments
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File
"/Users/zcorb/local/install/omniORB-4.0.3/lib/python2.3/site-packages/
CORBA.py", line 451, in ORB_init
File
"/Users/zcorb/local/install/omniORB-4.0.3/lib/python2.3/site-packages/
CORBA.py", line 462, in __init__
omniORB.CORBA.INITIALIZE: Minor: INITIALIZE_InvalidORBInitArgs,
COMPLETED_NO.
>>>
I'm pretty much certain this is caused by (some?) static constructors
in shared libraries not being run. Being a newbie to the OSX platform,
though, I'm still feeling my way through fixing the problem.
I found a couple of references to similar issues on this list but the
current config scripts seem to produce makefiles with all those
suggestions already implemented. Has anyone already figured this out?
Thanks!
--
Zac Corbiere
zcorb at fluidarch.com
------------------------------
Message: 3
Date: Fri, 5 Dec 2003 00:25:09 -0600
From: Zachery Corbiere <zcorb at fluidarch.com>
Subject: Re: [omniORB] omniORBpy 2.3 and Mac OSX
To: Zachery Corbiere <zcorb at fluidarch.com>
Cc: omniorb-list at omniorb-support.com
Message-ID: <C65F10FF-26EB-11D8-8DBF-000A95C729A2 at fluidarch.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Dec 4, 2003, at 10:21 PM, Zachery Corbiere wrote:
> I'm pretty much certain this is caused by (some?) static constructors
> in shared libraries not being run. Being a newbie to the OSX
> platform, though, I'm still feeling my way through fixing the problem.
Yay, replying to my own article. So after further investigation, I
found that in this code in orbOptions.cc:
orbOptions&
orbOptions::singleton() {
static orbOptions* singleton_ = 0;
if (!singleton_) {
singleton_ = new orbOptions();
}
return *singleton_;
}
singleton_ is actually initialized twice, to different values (!?!). I
also put debug printf's in the orbOptions constructor to verify that it
is being called twice. Below is the output of my debug prints. This
is executing at the python REPL:
>>> import omniORB
Creating orbOptions 30e6f0, thread: -1610571284.
inited singleton 30e6f0.
&singleton_=114caac
*** malloc[29251]: error for object 0x311240: Double free
begin reg InitRef handler.
end reg InitRef handler.
Creating orbOptions 30e710, thread: -1610571284.
inited singleton 30e710.
&singleton_=114caac
>>>
Of special note are the begin and end reg InitRef handler lines, which
are printfs I inserted in initRefs.cc around the registration of the
InitRef handler. Those regs are run against one singleton_ value and
then another is created and, apparently, overwrites the pointer for the
first.
I now doubt this is due to static constructors not being run. That's
what I get for guessing :-)
--
Zac Corbiere
zcorb at fluidarch.com
------------------------------
Message: 4
Date: Fri, 5 Dec 2003 17:42:00 +0800
From: Cameron Rochester <Cameron.Rochester at Ripple-Systems.com>
Subject: [omniORB] constructing an IOR
To: omniorb-list at omniorb-support.com
Message-ID:
<D191AA42E50BD711A59E00E08121DD1F42F6EA at envelope.pth.motherwell.com.au>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I am just wondering if it is possible to construct an IOR (object reference)
on a client machine to communicate with an Object on a server. The server is
activating the with an ID that is comprised of a Database key.
>From the client I can create the ObjectID, and the repoID, of the remote
object (as I have the interface, and the Database key) as well as the host
and port on which the server is running (through other means). What I want
to know if it is possible to formulate an IOR with this information so that
I don't have to resolve the Object from the naming service. Note: I don't
want to use the omniINSPOA to do this.
The bit that I am unsure about is what makes up the object_key section of
the IOR and if there is easy way I can create it..
Any help appreciated
Thanks
Cameron
------------------------------
Message: 5
Date: Fri, 5 Dec 2003 12:02:45 +0100
From: "FredP" <frederic.prin at silvaco.com>
Subject: [omniORB] OmniNotify2.0beta for Solaris 5.8 64bits
To: <omniorb-list at omniorb-support.com>
Message-ID: <0df601c3bb1f$864624b0$180a420a at bargy>
Content-Type: text/plain; charset="iso-8859-1"
Hello all,
Is there someone who succeed building omniNotify2.0beta for sparc Solaris
5.8 64bit ?
I use the configure script.
First question:
How to tell the compiler to compile in 64bits mode ??
Thanks
------------------------------------------------------------
Frédéric Prin Software Engineer
Silvaco G.RE.CE
----- Original Message -----
From: "FredP" <frederic.prin at silvaco.com>
To: <omniorb-list at omniorb-support.com>
Sent: Tuesday, December 02, 2003 5:16 PM
Subject: [omniORB] HPUX11 and -AA aCC option
> Hi all,
>
> omniORB4.0.1 for HPUX c++ code is compiled WITHOUT the -AA option:
>
> I use omniORB 4.0.1 with TRADITIONAL build; my aCC version is aCC: HP ANSI
> C++ B3910B A.03.39
> It's not the same with which omniORB / HPUX had been tested.
>
>
> ---- extract of hppa_hpux_11.00.mk ----
> CXXOPTIONS += -w +inst_v +DAportable \
> -D_THREAD_SAFE \
> -DRWSTD_MULTI_THREAD \
> -DRW_MULTI_THREAD
> ---------------------
> can someone confirm this ?
>
> man of aCC tells that
> > -AA Turns on newly supported ANSI C++ Standard features
> > like namespace std and the new C++ Standard
Library.
> > This option also implies -Aa. Include paths are
> > changed to include_std and libraries are libCsup_v2
> and
> > libstd_v2.
> > NOTE: Objects and libraries compiled with -AA are
> > binary incompatible with objects and libraries
> compiled
> > without -AA.
>
> we use to compile WITH -AA option!
>
> I try to add -AA option to CXXOPTIONS but the compiles fails.
>
> Is someone has experienced such incompatibilities ?
> When I compile my programs (with -AA) against omniORB libs (compiled
> without -AA) I have a lot of warnings and future error; Is someone has
> experienced
> Do omniORB 4.0.3 use -AA ?
>
> Thanks for your help.
> and special thanks to Alex Tingle for helping me.
>
> ------------------------------------------------------------
> Frédéric Prin Software Engineer
> Silvaco G.RE.CE
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
------------------------------
Message: 6
Date: Fri, 5 Dec 2003 12:48:20 +0100
From: P?ncz?l Levente <Levente.Panczel at compuworx.hu>
Subject: FW: [omniORB] deleting active servants -- repost
To: "OmniORB support" <omniorb-list at omniorb-support.com>
Message-ID: <8B9A1DE75E14C44FAE8306FBC0FA22350A8C84 at mercury.hq.cw>
Content-Type: text/plain; charset="windows-1252"
Hi! I'm reposting my last message, 'cos I got no answer. The main point is: I want to know whether there is a way to customize the deletion of a servant (I need my servant to be deleted through a call to one of it's functions, wich might return a shared object handle which _must_be_ dlclose-d)
-----Original Message-----
From: Pánczél Levente
Sent: Wed 2003-12-03 13:40
To: Carlos; OmniORB support
Cc:
Subject: RE: [omniORB] deleting active servants
Sorry, there's still something wrong. I get what you told me, but a question remains:
If I get it right, then the last operand executed from the code of my Terminal class is the RET at the end of its destructor. As I understand: POA "delete"-s the servant (wich is really a RefCountServantBase deriviate). So only the POA is to know, when it is sefe to dlclose the shared object file containing the code, but only my code knows how and wich handle is to be closed. Is there any way to integrate into the POA to customize the destruction of a servant?
>> Hello!
>>
>>
>>>It sounds like you are deleting a servant, and expecting to be able to
>>>call deactivate_object in the servant's destructor. Are you? That is
>>>not permitted, since the POA is still holding a reference to the
>>>servant. You should never delete a servant directly, but use the
>>>servant reference counting provided by RefCountServantBase. That way,
>>>you just call deactivate_object, and your servant is deleted when the
>>>POA has finished with it.
>>
>>
>> Thanks Duncan! Though I really read that in the documentation, I forgot about it. So if I understand right, I have to do the following:
>> The POA's reference is held by the object. When I need the object to be deleted, I simply call POA::deactivate_object() and that releases both the POA and the servant?
>
>No, deactivate_object only calls the destructor of the servant.
>
>> This is not acceptable for me. See, I have terminal objects. They are servats to be remotely manageable. A terminal is incarnated az follows:
>> 1. TermObj.so is dlopen-ed, and so its lock count is incremented, the library_handle will be saved into the terminal.
>> 2. The entrypoint function is called, wich instatiates an object, and returns an interface (pure virtual base class) pointer to it, this increments an internal module_lock_count wich indicates when it is safe to close the shared object.
>> 3. The RootPOA's reference is saved in the terminal.
>> 4. The terminal's own Reference count is raised to 1 by being added to the list of local terminals.
>> 5. A thread is created for the terminal, wich in first step activates the terminal object using the saved POA_ptr, and it saves the returned ObjectId
>> 6. The thread finishes, and indicates termination. As a last step, it calls deactivate_object on the saved POA_ptr (RootPOA) with the saved ObjectId. (I don't think the POA registers the servant for deletion because of this, else I would get a lot of sigsegv-s in step 7 and 8 executed from another thread.)
>> 7. A manager noticing the dieing terminal calls Terminal::Release() upon deleting it from the object list.
>> 8. The point is that when the own reference count drops to 0 then:
>> 8.1. TerminalRelease() makes a "delete this;" to ensure object deletion. (I would be glad if anyone told me, that the destructor runs and finishes BEFORE the "delete" returns.) The destructor frees associated resources.
>
>No you can't do delete this because deactivate_object call the
>destructor of the object.
If deactivate_object really called the destructor (I think you mean "deleted the object") then it would have done it in step 6, and all the actions of step 7 and 8 would result in a sigsegv. But they don't.
>
>> 8.2. the module_lock_count is decremented by Terminal::Release() and if the module_lock_count happens to drop to 0, then the library_handle for the shared object file is returned by Terminal::Release() indicating that is should be dlclose-d. (It is my need that code outside the Terminal class closes the library, because I found that Linux was sometimes fast enough to close and _free_ the shared object from memory, while the last return statement of Terminal::Release() was about to be executed causing a sigsegv.)
>> 9. Finished with the terminal.
>>
>> Though I don't do such things, I don't understand why it is illegal to call deactivate_object from it's destructor.
>
>Because deactivate_object calls the destructor of the servant.
>
>> What am I doing wrong now? And could you suggest me a way to get rid of the servant in a fashion conforming with the ORB's operation, and also to have a chance to dlclose the shared object on time.
>>
>> Thank you.
>> Panczel, Levente
>>
>
>I expect that this can help you.
>
>Cheers.
>
>Carlos.
>
Maybe I have to take a closer look at the refcounts. If you're right then the only problem I can imagine is that the servant's inherited reference count never reaches 0, and thatswhy the POA never tries to delete it.
------------------------------
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
End of omniORB-list Digest, Vol 8, Issue 8
******************************************
More information about the omniORB-list
mailing list