[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
SourceForge.net
noreply at sourceforge.net
Fri Apr 28 19:05:26 CEST 2006
Bugs item #1478253, was opened at 2006-04-28 08:59
Message generated for change (Comment added) made by balducci
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: balducci (balducci)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_ctypes: undefined symbol: XGetExtensionVersion
Initial Comment:
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
----------------------------------------------------------------------
>Comment By: balducci (balducci)
Date: 2006-04-28 17:05
Message:
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
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2006-04-28 15:02
Message:
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?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470
More information about the Python-bugs-list
mailing list