Thread: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type
Status: Inactive
Brought to you by:
tack
From: Jade M. <ja...@gn...> - 2001-01-15 23:38:42
|
Hello all, I am trying to use the latest CVS version of Orbit-Python, but am having problems importing PortableServer. on import PortableServer I get undefined symbol: POAManager_PyObject_Type. I read the mail archives, but couldn't find a real solution to the problem, I have made sure that there are no older versions of Orbit-Python anywhere on my system. I am using Debian GNU/Linux on an i686, python 1.5.2. Any suggestions? -- Jade Meskill <ja...@gn...> GNU Enterprise http://www.gnue.org |
From: Jason T. <ta...@li...> - 2001-01-17 04:40:31
|
> Hello all, Hi Jade, > I am trying to use the latest CVS version of Orbit-Python, but am > having problems importing PortableServer. on import PortableServer I > get undefined symbol: POAManager_PyObject_Type. I read the mail > archives, but couldn't find a real solution to the problem, I have Christian Reis (on Dec 4) reported the problem was due to Python not passing RTLD_GLOBAL to dlopen(). RedHat packages a patched version, and since I used that, I never noticed the problem. He included a patch as well, if you want to check the archives. I consider this to be a bug in ORBit-Python, obviously. One shouldn't have to patch Python to make it work. I don't expect the problem will be excessively hard to avoid, but, sadly, I haven't had any time to hack on the project lately. (I wanted to work on it during the Christmas break but I was having problems with my teeth and dentists are awfully hard to come by around that time. :)) Fixing up ORBit-Python and preparing it for a 0.2.0 release is slowly edging up in priority on my personal TODO list. There's no point in my giving an ETA because I'm pathetic at managing my own time, but naturally I am accepting patches if you'd care to have your own hand at it. :) Cheers, Jason. |
From: Jade M. <ja...@gn...> - 2001-01-17 17:16:03
|
On Tue, Jan 16, 2001 at 11:45:48PM -0500, Jason Tackaberry wrote: > > Hello all, > > Hi Jade, > > > I am trying to use the latest CVS version of Orbit-Python, but am > > having problems importing PortableServer. on import PortableServer I > > get undefined symbol: POAManager_PyObject_Type. I read the mail > > archives, but couldn't find a real solution to the problem, I have > > Christian Reis (on Dec 4) reported the problem was due to Python not > passing RTLD_GLOBAL to dlopen(). RedHat packages a patched version, and > since I used that, I never noticed the problem. He included a patch as > well, if you want to check the archives. Hrm... I must've missed that posting. :( I will take another look and see if I can recommend a patch to debian also. Do you know if this has been fixed in later versions of Python (1.6 or 2.0)? > > I consider this to be a bug in ORBit-Python, obviously. One shouldn't > have to patch Python to make it work. I don't expect the problem will > be excessively hard to avoid, but, sadly, I haven't had any time to hack > on the project lately. (I wanted to work on it during the Christmas > break but I was having problems with my teeth and dentists are awfully > hard to come by around that time. :)) > > Fixing up ORBit-Python and preparing it for a 0.2.0 release is slowly > edging up in priority on my personal TODO list. There's no point in my > giving an ETA because I'm pathetic at managing my own time, but > naturally I am accepting patches if you'd care to have your own hand at > it. :) Well, I am very interested in the project as we are currently using it in the project I am working on (GNU Enterprise (http://gnue.org or http://www.gnu.org/projects/gnue)), we need it to bridge our python based UI to our CORBA based object server, and I am also using it at my Real Job(tm), so I will be getting a lot of use out of it. My C skillz are a little rusty (been using too much python lately :) but I will start to hack around and see what I can figure out. I have had some other strange problems also, but I will send that in a separate thread. -- Jade Meskill <ja...@gn...> GNU Enterprise http://www.gnue.org |
From: Roland M. <ma...@ec...> - 2001-01-17 17:34:42
|
Jade Meskill (2001-01-17 10:16:45 -0700) : > On Tue, Jan 16, 2001 at 11:45:48PM -0500, Jason Tackaberry wrote: [...] > > Christian Reis (on Dec 4) reported the problem was due to Python not > > passing RTLD_GLOBAL to dlopen(). RedHat packages a patched version, and > > since I used that, I never noticed the problem. He included a patch as > > well, if you want to check the archives. > > Hrm... I must've missed that posting. :( I will take another look > and see if I can recommend a patch to debian also. Do you know if > this has been fixed in later versions of Python (1.6 or 2.0)? There has been a message in the debian-python explaining that this RTLD_GLOBAL "bug" was in fact not one. See it in the archive at <URL:http://lists.debian.org/debian-python-0101/msg00058.html> Roland. -- Roland Mas Food, shelter, source code. -- Cyclic Software |
From: Jade M. <ja...@gn...> - 2001-01-17 18:08:21
|
On Wed, Jan 17, 2001 at 06:34:36PM +0100, Roland Mas wrote: > Jade Meskill (2001-01-17 10:16:45 -0700) : > > > On Tue, Jan 16, 2001 at 11:45:48PM -0500, Jason Tackaberry wrote: > [...] > > > Christian Reis (on Dec 4) reported the problem was due to Python not > > > passing RTLD_GLOBAL to dlopen(). RedHat packages a patched version, and > > > since I used that, I never noticed the problem. He included a patch as > > > well, if you want to check the archives. > > > > Hrm... I must've missed that posting. :( I will take another look > > and see if I can recommend a patch to debian also. Do you know if > > this has been fixed in later versions of Python (1.6 or 2.0)? > > There has been a message in the debian-python explaining that this > RTLD_GLOBAL "bug" was in fact not one. See it in the archive at > <URL:http://lists.debian.org/debian-python-0101/msg00058.html> > Ah OK. What the message suggests was what I was going to suggest next, basically you have to make a library that shares the common bits between CORBAmodule and PortableServermodule and link them to that library. This would be the most correct approach anyways IMHO, as it doesn't rely on patching python at all. -- Jade Meskill <ja...@gn...> GNU Enterprise http://www.gnue.org |
From: <jp...@ar...> - 2001-01-17 18:25:36
|
On Wed, 17 Jan 2001, Jade Meskill wrote: > Ah OK. What the message suggests was what I was going to suggest next, > basically you have to make a library that shares the common bits between > CORBAmodule and PortableServermodule and link them to that > library. This would be the most correct approach anyways IMHO, as it > doesn't rely on patching python at all. If I may chime in here, you may want to look at how pygtk does this -- see gtkmodule.[ch] in pygtk. Basically, one module needs to setup an structure of function pointers to the C functions that are to be made available to other modules. A pointer to this structure is then wrapped in a PyCObject and made available as an attribute of the module or as the return value of a Python callable C function. The problem with creating a shared library and having both modules link against it is that the shared library must then be in LD_LIBRARY_PATH or one of the system shared lib directories, which complicates installation / uninstallation. John ------------------------------------------------------------------------ Archaeopteryx Software, Inc. Wing IDE for Python www.archaeopteryx.com Take Flight! |
From: Christian R. R. <ki...@as...> - 2001-01-23 00:16:38
Attachments:
python-1.5.2-dl-global.patch
|
On Wed, 17 Jan 2001, Jade Meskill wrote: > > > Hrm... I must've missed that posting. :( I will take another look > > > and see if I can recommend a patch to debian also. Do you know if > > > this has been fixed in later versions of Python (1.6 or 2.0)? Ok, lucky I caught this this week :-) The issue is that Python should _not_ use RTLD_GLOBAL, since it does (if I may) namespace-pollution (ok, ok). Fix is a) Patch Python (oh, yes, lovely). It's easy and it's stupid and it's what I did. If you need to release stuff then I would definitely cry about it. Stuff will work on RH, of course. b) Fix orbit-python. Perhaps this sound harsh, but it's true: orbit-python needs to get some work done if it's to be used in a large application. I've been stumped on many little issues over it and I've considered learning Python modules and Orbit just to get it working. I just haven't got the time lately, it seems, and neither has Jason, unfortunately. I'm still considering it because of (check next post: bug) Take care, -- /\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil ~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311 |