Hello there, I'm working on a python extension module that I'm trying to install using the distutils setup tools and I am running into a strange linker problem. Here is the situation: I have a bunch of code (swig-wrapped C+ + in this instance) that I want to compile into a module. The compilation itself works just fine and so does the initial linking. The linker command that distutils spits out looks somewhat like this
g++ -bundle -undefined dynamic_lookup mymodule_wrap.o -o _mymodule.so -framework Carbon -framework Cocoa -framework ApplicationServices -framework AGL -framework OpenGL -framework GLUT - framework Cocoa /usr/lib/libz.dylib However, when I load the module in python a whole bunch of system symbols are undefined starting in this case with aglSwapBuffers ImportError: dlopen(_mymodule.so, 2): Symbol not found: _aglSwapBuffers Referenced from: _mymodule.so Expected in: dynamic lookup My understanding is that the _mymodule.so file should "know" that this symbol came out of the AGL framework and thus look for it there. I could understand if python wouldn't find the framework because of a DYLD_LIBRARY_PATH issue or the like but here the problem seems to be that the information from where the symbol came from is lost. If I do a "more" on the _mymodule.so file that seems to be indeed what happens. I see links to "/usr/lib/libz.dylib" and the system libraries in there but none to the frameworks. However, now comes the really interesting part. If I execute the *identical* command line from the same shell I called "python setup.py install" from I get a different library which *does* include the links to the frameworks. If I install that file instead of the original everything works as expected. So there seems to be a strange problem inside distutils. I looked at that source code but couldn't make any sense out of it. Any idea of what could cause this and how this could be fixed would be greatly appreciated Thanks Timo -- http://mail.python.org/mailman/listinfo/python-list
