Dear python maintainers,

apologies if I'm wrong or I'm missing some evident point.

Just built 2.5a2 on linux:

     myhost> uname -a
     Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST
2006 i686 unknown


I find that `make test' chokes in test_ctypes.

Running the single test with `./python -E -tt
./Lib/test/regrtest.py 
-l -v -s test_ctypes' gives me the output shown in the
attached file.


As far as I could google around, I seem to understand
that this
problem has already appeared in the past. Basically, it
is due to the
fact that libglut (version 3.7) does not contain the
XGetExtensionVersion function, which is instead defined
in libXi:

myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i
xgetextensionversion
         U XGetExtensionVersion

myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i
xgetextensionversion
00003930 T XGetExtensionVersion

I seem to understand that libglut should be dlopen'ed
together with
libXi, in order to have XGetExtensionVersion available.

Unfortunately, I don't speak python, so I'm not in the
position to
suggest any reasonable fix for this.

I send this message in the hope of making something
useful: if this is
not the case, please, accept my apologies.

I thank you very much for your time and effort in
maintaining python.

Ciao
Gabriele

Logged In: YES 
user_id=11105

I don't know enough about linux shared libraries, either, to
sugegst a fix or workaround.  OTOH, I'm also not able to
reproduce that problem on any of the linux machines that I
have access to.  What kind of system is this?

Logged In: YES 
user_id=1452725

Dear Thomas,

thank you for your reply.

I've investigated a little bit more the problem.

2.5a1 worked smoothly on test_ctypes: this
makes me think that the problem isn't in my box (it's
an old redhat-7.1, but I keep all the system
up-2-date: kernel,X11,glibc etc.).

Also, I've kept python up-2-date since 2.3.4 and never
seen this.

On the other hand, it is also true that the (verbose
mode) output of test_ctypes in 2.5a1, while showing a
test_GL line, does not contain any test_glu and/or
test_glut lines (which, together with test_gl, give
the errors in 2.5a2): so it might also be that these new
tests (test_glu and test_glut) make some local
(i.e. due to my box) problem evident.

However, I'm incline to think that there must be
something in 2.5a2 which has changed from 2.5a1:

=> Lib/ctypes/__init__.py heavily differ from 2.5a1 to
   2.5a2 (the error reported in the attached file I
   sent seems to have been generated in __init__.py)
=> also, the traceback in the attachment quotes a file
   Lib/ctypes/test/test_find.py, which I don't find in
   2.5a1
=> the error is quite reasonable: libglut.so.3 does
   not define XGetExtensionVersion, which is instead
   defined in libXi.so


I seem to understand that exactly this kind of problem
was reported in the following thread:
http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534

I've seen just now that you got involved there!

Well, as I said, I do not speak python, but from a
glance to the thread I seem to understand that the
problem could be in the use of RTLD_GLOBAL/RTLD_LOCAL
(I don't know what these are for, but I guess that
RTLD stands for RunTime Loader?)

As I understand it, the problem seems to be as if one
tries to compile a C program which calls
XGetExtensionVersion with -lglut, but without
-lXi. Perhaps the corresponding action should be done
with test_ctypes, but I have no idea how this is done
with python.


I've also to admit that being the only one who has
reported this problem on such a widespread platfrom
like linux makes me perplexed.

In the end, I don't know what to think: the problem is
actually there and was not there with 2.5a1 (nor with
any previous build since 2.3.4).

I regret being unable to go deeper in this problem and
I apoligize if this report is not clear enough.

If there is any test I can do to make things clearer,
please, just tell me.

And THANK YOU for your work.

Ciao
Gabriele

Logged In: YES 
user_id=11105

Gabriele, from the thread you mention I would assume that
this patch may fix the problem for you - it should be
applied to Lib/ctypes/test/test_find.py:

Index: test_find.py
===================================================================
--- test_find.py	(Revision 45791)
+++ test_find.py	(Arbeitskopie)
@@ -39,9 +39,9 @@
         if lib_glu:
             self.glu = CDLL(lib_glu, RTLD_GLOBAL)
         if lib_glut:
-            self.glut = CDLL(lib_glut)
+            self.glut = CDLL(lib_glut, RTLD_GLOBAL)
         if lib_gle:
-            self.gle = CDLL(lib_gle)
+            self.gle = CDLL(lib_gle, RTLD_GLOBAL)
 
     if lib_gl:
         def test_gl(self):


About the differences between ctypes in 2.5a1 and 2.5a2:

Python 2.5a2's ctypes contained changes that I had better
not made.  This has been reverted in 2.5a2 version, which
explains the large differences.  FWIW, it seems all the
Python buildbots and other systems that test the 2.5a2 code
doen't have the problem that you report.  Which does not
mean that your system is broken, just that it is different
(but similar to that one mentioned in the thread on
ctypes-users from last October)!

Please try the patch and report back.

Logged In: YES 
user_id=1452725

Dear Thomas,

I thank you very much for your time and effort.

I think I have solved the problem and, as I suspected,
the problem was on my side and not on python's.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I have two shared libglut's installed: one is from
orginal RedHat-7.1 distro and the other was installed
by me some time ago.

Now, if I check dependencies of the two libs, I get:

RedHat's libglut:
----------------
myhost>  ldd /usr/lib/libglut.so
linux-gate.so.1 =>  (0xffffe000)
libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000)
libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000)
libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef0000)
libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000)
libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000)
libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000)
libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000)
libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce0000)
libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000)
libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000)
/usr/local/glibc/lib/ld-linux.so.2 (0x80000000)


My libglut installation:
-----------------------
myhost> ldd /usr/local/X11R6/lib/libglut.so
linux-gate.so.1 =>  (0xffffe000)
libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000)
libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000)
/usr/local/glibc/lib/ld-linux.so.2 (0x80000000)

Things seem to be clear for me now: /usr/lib/libglut.so
contains all the necessary dependencies to resolve any
reference which is not defined in it, while
/usr/local/X11R6/lib/libglut.so does not contain any
dependency from the X11 libs, which instead is NEEDED
(e.g. the XGetExtensionVersion problem shown up).

In fact, if I run `LD_LIBRARY_PATH=/usr/lib make
test', i.e. force runtime loader to use
/usr/lib/libglut.so, everything works nicely, even
without the patch you sent. On the other hand, if
/usr/local/X11R6/lib/libglut.so is picked up, then the
errors occur and your patch does not solve the problem
(and it could not in any case, given the above, I guess).

Going back to my libglut installation notes, I could
verify that no X11 dependencies were compiled in (most
probably due to some misconfiguration by me).

In the end, I think you can close this (which is not
a) bug.

I apologize once again for wasting your time on an
issue which I could have investigated more deeply
before claiming a bug in python.

THANK YOU and
ciao
Gabriele

Logged In: YES 
user_id=849994

Closing. Thank you for your thorough investigation.