Thread: [PyOpenGL-Devel] Plans for a beta release sometime this week...
Brought to you by:
mcfletch
From: Mike C. F. <mcf...@ro...> - 2003-04-28 08:54:55
|
I'd like to get the point where we can do a beta release sometime in the next seven days or so. I will be spending a considerable portion of this week on PyOpenGL (and OpenGLContext). Here's what I like to see happen before the PyOpenGL beta (in case anyone would like to volunteer for items): * Python 2.3 compatibility o Currently the only problem appears to be Togl (I'm getting a segmentation fault him when trying to install, and there is an error during the build process where the API_version file is not present, I suspect a problem with mismatched Tk8.4.x builds). I don't know why it is expecting an API_version in that particular spot (I don't think togl is using API_version), will eventually track that down. o Test on Linux, preferably also Macintosh OSX * Python 1.5.2 compatibility o This hasn't been tested in... well, a long time. Anyone care ;) ? * RPMs for Red Hat o Set up the CVS repository's source to properly create the RPMs automatically with distutils o Requires defining the "provides" and "requires" specifications for the RPM system (not complex, but will probably take an hour or so) [MCF] * Build testing on Linux, Win32, OSX, (Sun, HP, Irix, AIX, *BSD) o Any pending patches/fixes should be called to my attention explicitly if they are not already integrated. o In essence, PyOpenGL should build properly from CVS without altering anything other than your platform .cfg file, preferably without requiring even that (where the platform's library/header locations are well-defined and predictable). o Inadequacies in the build instructions should be integrated into the installation/build documentation. + For instance, I have no idea what's required on OSX o I'll be posting a notice in a few days of a "build-candidate" in CVS (possible with a source tarball too) + Would be nice to get replies back for each built platform, with any notes on incompatabilities/problems. * Documentation re-generation [MCF] o For the beta release I would like to replace the current "manual" with just the reference converted with the modern doc-book XSLT. o The added-information sections (the "user manual") which are still relevant will likely be provided as a separate document. o Note that there is no current method available to me to create PNG-based equations, so the math-ml-based equations will almost certainly carry on for now. o The PDF engine requires the PNG-format equations, so similarly we likely won't have that * PyPi registration [MCF] o I've added the metadata required by PyPi, will register the project with the next release * Website review and update [MCF] o Basically do a review, nothing significant planned, just looking for bit-rot * Get un-attended build environment to our Win32 packaging volunteer o (build said environment ;) ) o If Rene has his copy of VC++ yet, this may be unnecessary (hope springs eternal :) ) * Linux/*nix niceties [volunteers?] o #! lines for all "script" .py files [MCF] o Make sure the files are all going to the right places o Make sure all files have proper permissions o Make sure various install types work (e.g. with su, without, however that works on Unix, make sure I haven't mistakenly included my own username or something silly like that in the RPMs (when I build them)) * Establish the set of distributable packages intended (may as well do that now, note that these are ones I would like to have *eventually* for the release if they are not "core", doesn't have to occur this week). Volunteers willing to act as packagers for the various platforms feel free to let me know who you are :) : o Core + Win32 Binary (w/ HTML Documentation) + Linux RPM + .zip and .tar.gz source distributions (w/ swig-generated wrappers) + HTML Documentation o Nice to have if possible + Mac bundle (not sure what these are actually called) + Red-Hat source RPM + Red-Hat docs RPM (or should that be part of source?) + .deb ? (is this something that the Debian maintainers do?) + .bsd ? (not sure there is a package format for the .bsd operating systems other than darwin, if so, would be nice to support that, will obviously require someone who has such a system ;) ). o For each binary format (I'm not sure we actually need to different versions for the different Tk versions, the theory, I believe, is that when built with 8.4 it should be compatible with a .3): + Python 2.3, {Numpy 23, Numpy 21}, {Tk83, Tk84}? + Python 2.2, {Numpy 23 (post-change), Numpy 21(pre-change)}, {Tk83, Tk84}? + Python 1.5.2, {Numpy 21}, {Tk83, Tk84}? -- realistically, I would like to drop this, as it seems hopelessly out of date Given the relatively slow pace of development for PyOpenGL (barring the introduction of a new C developer), I would imagine the beta period will be about two or three months to give people time to actually try this version with their applications, get error reports and patches in, and do the next release. Of course, if there is a reason, we can do another beta, but really, this is just a minor point release, primarily build and bug fixes (with the exception of the togl version shift), so I'm hoping we won't run run into anything significant. I'm expecting the beta to be basically stable, barring some significant mess-up on my part. Enjoy yourselves, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Thomas W. <th...@xs...> - 2003-04-28 12:23:47
Attachments:
PyOpenGL2.togl.diff
|
On Mon, Apr 28, 2003 at 04:54:45AM -0400, Mike C. Fletcher wrote: > * Python 2.3 compatibility > o Currently the only problem appears to be Togl (I'm getting a > segmentation fault him when trying to install, and there is > an error during the build process where the API_version file > is not present, I suspect a problem with mismatched Tk8.4.x > builds). I don't know why it is expecting an API_version in > that particular spot (I don't think togl is using > API_version), will eventually track that down. I'm using the patch on my Linux system; now that Togl is 1.6-CVS, we can remove the need to have a Tk-version-specific include directory. > o Test on Linux, preferably also Macintosh OSX Don't have the latter right now, but I've been doing some of my OGL stuff on PyOpenGL2-CVS, on Debian, using my own packages. > o Make sure the files are all going to the right places > * Establish the set of distributable packages intended > o Nice to have if possible > + .deb ? (is this something that the Debian maintainers do?) The Debian maintainer for PyOpenGL 1.5 doesn't really have the time to do it. I've created my own .deb's for PyOpenGL 2.0.0 and will create them for PyOpenGL 2.0.1, but I'm not sure when they'll get into Debian unstable. > .bsd operating systems other than darwin, if so, would > be nice to support that, will obviously require > someone who has such a system ;) ). Most BSD systems work with 'ports', which is basically a makefile with instructions on how to download, build and install. It's not terribly difficult but it's fairly tightly integrated. There are also binary packages for some BSD systems, but I never made one myself. It's probably better to leave this up to the BSD 'vendor' in question. > o For each binary format (I'm not sure we actually need to > different versions for the different Tk versions, the > theory, I believe, is that when built with 8.4 it should be > compatible with a .3): Yes, Togl 1.6-CVS is binary compatible with Tk as far back as 8.2, so there's no need to build seperate binaries for it. > + Python 1.5.2, {Numpy 21}, {Tk83, Tk84}? -- > realistically, I would like to drop this, as it seems > hopelessly out of date I personally think it's fine to drop 1.5.2 support, but I may be biased :) -- Thomas Wouters <th...@xs...> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! |
From: Rene D. <il...@ya...> - 2003-04-29 05:18:25
|
Mike C. Fletcher wrote: > * Python 1.5.2 compatibility > o This hasn't been tested in... well, a long time. Anyone care > ;) ? I think we could drop this. It works on debian with 1.52. You need to install distutils, as it doesn't come with python 1.52. Not tried with tk, or numeric though. They don't even package numeric for 1.52 on debian anymore. > > * Get un-attended build environment to our Win32 packaging volunteer > o (build said environment ;) ) > o If Rene has his copy of VC++ yet, this may be unnecessary > (hope springs eternal :) ) After three months I didn't get my copy, so I cancelled the order. With such a bad taste in my mouth I'm not going to buy a copy(if that is in fact possible ;) but instead try and get mingw(gcc) working on windows with pyopengl. Just got numeric working with it, as well as a couple of smaller swig projects. Now to make sure mingw can make opengl apps properly. Then onto the fun of pyopengl ;) Unfortunately python itself doesn't compile out of the box with mingw. Hopefully that's fixed up for python2.3. If we can get a version of pyopengl which is really easy to compile on windows/msvc Geoff has volunteered to make release builds for us :) Have fun! |
From: Rene D. <il...@ya...> - 2003-04-29 07:31:16
|
Hi, I've noticed that the problem is with the interface_util. It needs to have libpython22 and libglut linked, but it's not getting it. I'm not sure exactly how to add this in. Anyone have any ideas? Here are the error messages. Compiled with CC build\temp.win32-2.2\Release\gle.o(.text+0x12):GLE.c: undefined reference to `__glutInitWithExit@12' build\temp.win32-2.2\Release\gle.o(.text+0x2b):GLE.c: undefined reference to `__glutCreateWindowWithExit@8' build\temp.win32-2.2\Release\gle.o(.text+0x45):GLE.c: undefined reference to `__glutCreateMenuWithExit@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x12):interface_util.c: undefined reference to `__glutInitWithExit@12' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2b):interface_util.c: undefined reference to `__glutCreateWindowWithExit@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x45):interface_util.c: undefined reference to `__glutCreateMenuWithExit@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x92):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xc1):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x116):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x141):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x19b):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1cb):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x220):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x24b):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x28d):interface_util.c: undefined reference to `_imp__PyLong_FromUnsignedLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x29e):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2bb):interface_util.c: undefined reference to `_imp__PyLong_FromUnsignedLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2c7):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x31a):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x343):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x399):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x3c5):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x41b):interface_util.c: undefined reference to `_imp__PyTuple_New' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x448):interface_util.c: undefined reference to `_imp__PyTuple_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x4cd):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x4eb):interface_util.c: undefined reference to `_imp__PyString_FromStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x5a5):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x680):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x760):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x83a):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x855):interface_util.c: undefined reference to `_imp__PyLong_FromUnsignedLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x912):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x9ea):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xac6):interface_util.c: undefined reference to `_imp__PyList_SetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xc06):interface_util.c: undefined reference to `_imp__PyExc_Exception' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xc48):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xc54):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xc84):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xc90):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xca2):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xcae):interface_util.c: more undefined references to `glPixelStorei@8' follow build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xdd9):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0xde8):interface_util.c: undefined reference to `_imp__PyExc_Exception' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x101f):interface_util.c: undefined reference to `_imp__PyExc_Exception' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1042):interface_util.c: undefined reference to `glGetIntegerv@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x10ab):interface_util.c: undefined reference to `glGetIntegerv@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x10b9):interface_util.c: undefined reference to `glGetIntegerv@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1138):interface_util.c: undefined reference to `glGetIntegerv@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1158):interface_util.c: undefined reference to `glGetIntegerv@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1188):interface_util.c: more undefined references to `glGetIntegerv@8' follow build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x11f4):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1212):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x121e):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x124e):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x125a):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x126c):interface_util.c: undefined reference to `glPixelStorei@8' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1278):interface_util.c: more undefined references to `glPixelStorei@8' follow build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x12f6):interface_util.c: undefined reference to `_imp__PyString_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1305):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1324):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x133c):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x138f):interface_util.c: undefined reference to `_imp__PyNumber_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x13da):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1419):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1438):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1452):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x14a5):interface_util.c: undefined reference to `_imp__PyNumber_Float' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x14c6):interface_util.c: undefined reference to `_imp__PyFloat_AsDouble' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x15ca):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1605):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1696):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x16d5):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x16f4):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x170e):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1761):interface_util.c: undefined reference to `_imp__PyNumber_Float' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1782):interface_util.c: undefined reference to `_imp__PyFloat_AsDouble' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x17da):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1815):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x18a6):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x18db):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x18fa):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1914):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1964):interface_util.c: undefined reference to `_imp__PyNumber_Int' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1985):interface_util.c: undefined reference to `_imp__PyInt_AsLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x19d9):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1a14):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1aa4):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1ad9):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1af8):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1b12):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1b62):interface_util.c: undefined reference to `_imp__PyNumber_Int' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1b83):interface_util.c: undefined reference to `_imp__PyInt_AsLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1bd7):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1c12):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1ca2):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1cda):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1cf9):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1d13):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1d66):interface_util.c: undefined reference to `_imp__PyNumber_Int' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1d87):interface_util.c: undefined reference to `_imp__PyInt_AsLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1ddf):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1e1a):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1eaa):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1ee2):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1f01):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1f1b):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1f6e):interface_util.c: undefined reference to `_imp__PyNumber_Int' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1f8f):interface_util.c: undefined reference to `_imp__PyInt_AsLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x1fe7):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2022):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x20b2):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x20e8):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2107):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2121):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2174):interface_util.c: undefined reference to `_imp__PyNumber_Int' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2195):interface_util.c: undefined reference to `_imp__PyInt_AsLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x21ec):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2227):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x22b8):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x22ee):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x230d):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2327):interface_util.c: undefined reference to `_imp__PySequence_GetItem' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x237a):interface_util.c: undefined reference to `_imp__PyNumber_Long' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x239b):interface_util.c: undefined reference to `_imp__PyLong_AsUnsignedLong' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x23f2):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x242d):interface_util.c: undefined reference to `_imp__PyExc_ValueError' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2494):interface_util.c: undefined reference to `_imp__PyObject_Str' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x249d):interface_util.c: undefined reference to `_imp__PyString_AsStringAndSize' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x24aa):interface_util.c: undefined reference to `_imp__PyMem_Malloc' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x24e1):interface_util.c: undefined reference to `_imp__PySequence_Check' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x24fb):interface_util.c: undefined reference to `_imp__PySequence_Size' build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x2534):interface_util.c: undefined reference to `_imp__PySequence_GetItem' dllwrap: gcc exited with status 1 |
From: Mike C. F. <mcf...@ro...> - 2003-04-29 22:42:22
|
The way to add libs as far as the dist.py module is concerned is to add this to the top of GLE.i # BUILD libs ['GLUT','Python'] (in the section with all the other # BUILD declarations). However, that's not what's causing the problem AFAICS (adding the declaration produces the same failures, and really _everything_ is linking to Python, so specifying that is an obvious "there's a problem"). Stil looks like problems with incompatabilities between the GLUT and Python .lib files and the ones generated by Mingw32. I.e. it still looks like name-mangling issues :( . BTW, documentation generation is coming along, though every hour I spend on it is making me hate XML/XSLT just that much more (even with Saxon, the change-generate-view cycle is in the 30 minute range). Ideas still welcome regarding mingw32, of course, Mike Rene Dudfield wrote: > Hi, > > I've noticed that the problem is with the interface_util. It needs to > have libpython22 and libglut linked, but it's not getting it. I'm not > sure exactly how to add this in. Anyone have any ideas? > > > > Here are the error messages. > > Compiled with CC > build\temp.win32-2.2\Release\gle.o(.text+0x12):GLE.c: undefined > reference to `__glutInitWithExit@12' > build\temp.win32-2.2\Release\gle.o(.text+0x2b):GLE.c: undefined > reference to `__glutCreateWindowWithExit@8' > build\temp.win32-2.2\Release\gle.o(.text+0x45):GLE.c: undefined > reference to `__glutCreateMenuWithExit@8' > build\temp.win32-2.2\libinterface_util.a(interface_util.o.b)(.text+0x12):interface_util.c: > undefined reference to `__glutInitWithExit@12' ... _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Mike C. F. <mcf...@ro...> - 2003-05-04 06:04:02
|
Mike C. Fletcher wrote: ... > * Python 1.5.2 compatibility > o This hasn't been tested in... well, a long time. Anyone care > ;) ? ... Okay, I've just built and tested the latest CVS version with Python 1.5.2 (Tk 8.0) on Win2K. Had a few cosmetic changes to make to get it working, but it does appear to be basically functional. There's a failure in the gle knots demo, but everything else in the OpenGL/Demo directory works as expected. BTW, PyOpenGL will use Togl 1.5 for Python versions < 2.2.0, as the 1.6 version doesn't properly compile with Tk 8.0-era headers. Let me know if that's a problem (and you have a solution ;) ). If people care enough to build on other platforms, that's cool, but I'm going to consider this item finished for now. Enjoy, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Thomas W. <th...@xs...> - 2003-05-04 09:54:20
|
On Sun, May 04, 2003 at 02:03:50AM -0400, Mike C. Fletcher wrote: > Mike C. Fletcher wrote: > > * Python 1.5.2 compatibility > > o This hasn't been tested in... well, a long time. Anyone care > > ;) ? > Okay, I've just built and tested the latest CVS version with Python > 1.5.2 (Tk 8.0) on Win2K. Had a few cosmetic changes to make to get it > working, but it does appear to be basically functional. There's a > failure in the gle knots demo, but everything else in the OpenGL/Demo > directory works as expected. BTW, PyOpenGL will use Togl 1.5 for Python > versions < 2.2.0, as the 1.6 version doesn't properly compile with Tk > 8.0-era headers. Let me know if that's a problem (and you have a > solution ;) ). Why don't you just check _tkinter.VERSION ? Back when I still had Python 1.5.2 with Tkinter, it wasn't built against anything that doesn't handle stubs (pre-8.1) and 2.0 and 2.1 definately aren't, on my systems :) -- Thomas Wouters <th...@xs...> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! |
From: Mike C. F. <mcf...@ro...> - 2003-05-04 20:19:50
|
Thomas Wouters wrote: ... >Why don't you just check _tkinter.VERSION ? Back when I still had Python >1.5.2 with Tkinter, it wasn't built against anything that doesn't handle >stubs (pre-8.1) and 2.0 and 2.1 definately aren't, on my systems :) > > I'm growing less and less convinced that stubs work with TCL/Tk (at least on Win32), or at least, that they don't seem to be getting included in the togl build. As for why I didn't check _tkinter.VERSION, mostly 'cause I never use Tkinter and didn't know it existed. Will work on it again now. 1.5.2 comes with Tk 8.0 on Win32, BTW. Have fun, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Thomas W. <th...@xs...> - 2003-05-04 20:32:20
|
On Sun, May 04, 2003 at 04:19:31PM -0400, Mike C. Fletcher wrote: > Thomas Wouters wrote: > >Why don't you just check _tkinter.VERSION ? Back when I still had Python > >1.5.2 with Tkinter, it wasn't built against anything that doesn't handle > >stubs (pre-8.1) and 2.0 and 2.1 definately aren't, on my systems :) > I'm growing less and less convinced that stubs work with TCL/Tk (at > least on Win32), or at least, that they don't seem to be getting > included in the togl build. As for why I didn't check _tkinter.VERSION, > mostly 'cause I never use Tkinter and didn't know it existed. Will work > on it again now. Well, from what I've seen of the CVS version of Togl, you can't not use stubs. They are always 'included'. It might be that they aren't really binary compatible with previous versions of Tcl/Tk on Win32, but they seem to be so on Linux... I would test it if I had a Win32 compiler ;) -- Thomas Wouters <th...@xs...> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! |
From: Mike C. F. <mcf...@ro...> - 2003-05-04 08:30:37
|
Mike C. Fletcher wrote: > I'd like to get the point where we can do a beta release sometime in > the next seven days or so. I will be spending a considerable portion > of this week on PyOpenGL (and OpenGLContext). Here's what I like to > see happen before the PyOpenGL beta (in case anyone would like to > volunteer for items): > > * Python 2.3 compatibility 2.3 is basically functional. Togl doesn't work, though the only thing that seems to be stopping it is the explicit Tk version check in Togl. I've added flags [('USE_TCL_STUBS',1),('USE_TK_STUBS',1)], but I'm still not getting a usable Togl for Tk 8.4. I'd like to get this fixed for tomorrow. > o Test on Linux, preferably also Macintosh OSX > * Python 1.5.2 compatibility As noted earlier, this now works. > * RPMs for Red Hat > o Set up the CVS repository's source to properly create the > RPMs automatically with distutils > o Requires defining the "provides" and "requires" > specifications for the RPM system (not complex, but will > probably take an hour or so) [MCF] Still pending. > * Build testing on Linux, Win32, OSX, (Sun, HP, Irix, AIX, *BSD) > o Any pending patches/fixes should be called to my attention > explicitly if they are not already integrated. o > In essence, PyOpenGL should build properly from CVS without > altering anything other than your platform .cfg file, > preferably without requiring even that (where the platform's > library/header locations are well-defined and predictable). Haven't had any submitted patches, so I'm assuming everything builds. Will do a build-candidate for testing tomorrow. > * Documentation re-generation [MCF] Completed. > * PyPi registration [MCF] Still waiting for the release itself. > * Website review and update [MCF] > o Basically do a review, nothing significant planned, just > looking for bit-rot Not done yet. > * Get un-attended build environment to our Win32 packaging volunteer > o (build said environment ;) ) > o If Rene has his copy of VC++ yet, this may be unnecessary > (hope springs eternal :) ) Still not done yet. > * Linux/*nix niceties [volunteers?] Have Thomas' message on permissions, though I still haven't found where to put my finger to solve the problem. Other than that I'm not planning to fix anything before tomorrow. Enjoy all, Mike |