From: K.-Michael A. <kmi...@gm...> - 2012-04-19 22:07:39
|
On 2012-04-19 21:14:03 +0000, K.-Michael Aye said: > On 2012-04-19 20:47:24 +0000, Bruce Sherwood said: > >> I've not seen this in building for the Mac starting from a python.org >> distribution of Python. Line 50 in src/core/util/gl_extensions.cpp >> doesn't look much like the error that's reported, which is puzzling. Because of this statement I made 'make clean', changed the python dist in the makefile to the python.org python 2.7 and tried again, resulting in the same error. One question: python.org's 2.7 python is compiled with GCC 4.2.1: (master+)[maye@paradigm ~/Dropbox/src/mbuild]$ python Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin But in your makefile you state: # Use 4.0 compiler rather than 4.2 so as to build in a way compatible with OSX 10.5 How does that fit with the requirement that the boost libs had to be compiled with the same gcc version as the python we are building against? Isn't that inconsistent? As I don't have a g++4.0 available, all my trials are done with g++4.2, could this be our difference? Even so, I also need to understand above inconsistency, if it exists. Another oddity: the boost compile is now asking to use ./b2 instead of ./bjam. Indeed ./bjam even fails on me completely, while ./b2 only fails for the compilation of the .dylibs. The static ones are created fine though. But as I am not yet at linking stage that is for sure not the reason for the gl_extensions compile error. Michael >> >> You mention "boost_source", which I don't understand. The >> "dependencies" folder should contain the following: >> >> threadpool folder >> boost_files folder, containing >> boost folder of Boost library includes > > Aha! That's how. I believe that this is missing from the MAC-OSX.txt > build instructions. > I now removed my added boost_source include, added a > > ln -s /Users/maye/Dropbox/src/boost_1_49_0/boost > > into dependencies/boost_files and it works as before, compiling fine > until the gl_extensions problem. > > If you want, I can add this info to MAC-OSX.txt and send you a git pull > request from my fork? Maybe a good time to practice those github > collaboration features, as I understand that visual only recently got > there? ;) > > I agree that line 50 does not look like it at all: > > if ( EXT_texture3D = d.hasExtension( "GL_EXT_texture3D" ) ) { > F( glTexImage3D ); > F( glTexSubImage3D ); > } else { > #ifdef __APPLE__ > // Supported natively but NOT as an extension > EXT_texture3D = true; > 50 --> glTexImage3D = ::glTexImage3D; > glTexSubImage3D = ::glTexSubImage3D; > #endif > } > > > but maybe this ifdef __APPLE__ has something to do with it? > > > Michael > > >> mac_libs folder containing >> libboost_python.a >> libboost_signals.a >> libboost_thread.a >> >> Bruce Sherwood >> >> On Thu, Apr 19, 2012 at 2:18 PM, K.-Michael Aye <kmi...@gm...> wrote: >>> Okay, some steps further in my endavour to build visual for EPD, I am >>> now using the standard makefile for MacOS, but had to add the >>> boost_source folder for including the boost header files (maybe i >>> messed something up at compile time there, let's see). >>> >>> But currently I am blocked by not compiling gl_extensions: >>> >>> g++ -fPIC -MMD -DNDEBUG -mmacosx-version-min=10.5 -arch i386 -DPIC -O2 >>> -g -finline-functions -I../boost_1_49_0 -I../visual/include/mac >>> -I../visual/include >>> -I/Library/Frameworks/Python.framework/Versions/Current/include/python2.7 >>> -I/Library/Frameworks/Python.framework/Versions/Current/lib/python2.7/site-packages/numpy/core/include >>> >>> >>> -I../visual/dependencies/boost_files >>> -I../visual/dependencies/threadpool/include >>> -F/System/Library/Frameworks/AGL.framework >>> -F/System/Library/Frameworks/Carbon.framework >>> -F/System/Library/Frameworks/OpenGL.framework -c -o gl_extensions.o >>> ../visual/src/core/util/gl_extensions.cpp >>> ../visual/src/core/util/gl_extensions.cpp: In member function ‘void >>> cvisual::gl_extensions::init(cvisual::display_kernel&)’: >>> ../visual/src/core/util/gl_extensions.cpp:50: error: invalid conversion >>> from ‘void (*)(GLenum, GLint, GLint, GLsizei, GLsizei, GLsizei, GLint, >>> GLenum, GLenum, const GLvoid*)’ to ‘void (*)(GLenum, GLint, GLenum, >>> GLsizei, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)’ >>> make: *** [gl_extensions.o] Error 1 >>> >>> >>> Has anybody ever seen such an error and remembers what was wrong? >>> >>> TIA, >>> Michael >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> _______________________________________________ >>> Visualpython-users mailing list >>> Vis...@li... >>> https://lists.sourceforge.net/lists/listinfo/visualpython-users >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users > > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |