Mailing List Archive

Bill Janssen <janssen@parc.xerox.com> writes:

> After a fair amount of grief, I found out that while Python 1.5
> specified RTLD_GLOBAL in its call to dlopen (in Python/importdl.c),
> Python 1.5.2 does not. Is there any particular reason to change this?

It was thrashed out here a while's back. www.deja.com is your
friend... I think there was also discussion on PSA-members or some sig
or other.

I think the basic gist was that if not using RTLD_GLOBAL causes you
problems you can do something about it, whereas if using RTLD_GLOBAL
causes you problems you are screwed.

> To be compatible with Java?

I doubt it.

> Bill

HTH
Michael

Bill Janssen wrote:
>
> After a fair amount of grief, I found out that while Python 1.5
> specified RTLD_GLOBAL in its call to dlopen (in Python/importdl.c),
> Python 1.5.2 does not. Is there any particular reason to change this?

Make that double the grief, please - it bit me too, when building the
Minotaur cross-language scripting extension. Ended up editing Python
1.5.2 and rebuilding (and mucking with the makefile to end up with a
shared lib version of Python under Linux - but that's another thread).

Michael Hudson followed up by mentioning that RTLD_GLOBAL was discussed
here before. If a shared lib has conflicting entry points, can't the
person who needs it write a wrapper extension which loads that offending
shlib without RTLD-GLOBAL? I hope the onus of dealing with such a
conflict can be on the trouble-makers, not everyone else? I haven't
looked into prior discussions, and may be missing the point completely
(yah, it happens, a lot).

-- Jean-Claude

Michael Hudson:
|Bill Janssen <janssen@parc.xerox.com> writes:
|
|> After a fair amount of grief, I found out that while Python 1.5
|> specified RTLD_GLOBAL in its call to dlopen (in Python/importdl.c),
|> Python 1.5.2 does not. Is there any particular reason to change this?
|
|It was thrashed out here a while's back. www.deja.com is your
|friend... I think there was also discussion on PSA-members or some sig
|or other.
|
|I think the basic gist was that if not using RTLD_GLOBAL causes you
|problems you can do something about it, whereas if using RTLD_GLOBAL
|causes you problems you are screwed.

(A little late catching up on the Python folder)

This bit me a few months ago as well. If you're dlinking with C wrappers
which dlink with a library you don't have source for (which has undefined
unreferenced symbols that don't matter when linking with C programs),
you've got some work to do.

Either beg/borrow/steal the source and recompile it, define or remove the
undefined dynamic symbols one way or another, put the library in another
process, ...or just hack Python before you build it and remove that dlopen
flag.

Randall