search

BruceSherwood / vpython-wx

VPython based on wxPython
Other
70 stars 38 forks source link

change GLhandleARB to (void*) in OS X 10.7+ with appropriate typecasts #48

Closed AprilArcus closed 10 years ago

BruceSherwood commented 10 years ago

I'm reluctant to execute this pull request without further discussion for fear of breaking the existing machinery which, with Python from python.org, does build on OSX 10.8. This is quite puzzling.

Bruce

On Tue, Apr 8, 2014 at 11:29 PM, April Arcus notifications@github.comwrote:

You can merge this Pull Request by running

git pull https://github.com/AprilArcus/vpython-wx master

Or view, comment on, or merge it at:

https://github.com/BruceSherwood/vpython-wx/pull/48 Commit Summary

File Changes

  • M include/GL/glext.hhttps://github.com/BruceSherwood/vpython-wx/pull/48/files#diff-0(8)
  • M include/util/shader_program.hpphttps://github.com/BruceSherwood/vpython-wx/pull/48/files#diff-1(4)
  • M src/core/util/shader_program.cpphttps://github.com/BruceSherwood/vpython-wx/pull/48/files#diff-2(18)

Patch Links:

Reply to this email directly or view it on GitHubhttps://github.com/BruceSherwood/vpython-wx/pull/48 .

AprilArcus commented 10 years ago

I would in fact be dismayed if you accepted a pull request without first verifying that it builds on your test systems. Please try it and let me know.

I'm not sure why you believe this issue to be related to the particular distribution of Python being used - the problem is a conflicting typedef in

/System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h

Is it possible that your 10.8 machine is somehow linking against old 10.6 OpenGL headers? Maybe you could try building on a clean install to exclude that possibility?

If the build is successful on a clean install of 10.8, we can always change the #ifdef in glext.h to __MAC_10_9. (I have now reproduced the error on two 10.9 machines)

sspickle commented 10 years ago

Hi Bruce,

My recollection of “10.8” is just that, my recollection.

1) I could be wrong. Maybe it was 10.7, I don’t recall exactly when I upgraded. I’m sure it wasn’t 10.6. 2) I could be right. Maybe I somehow got a different SDK involved. I have several SDK versions installed. I try to keep them sorted out, but it’s hard sometimes to keep track.

In any case, Unfortunately I’m not going to have much time to dig into this again for a couple of weeks. I’m in the thick of too many competing projects at the moment. Sorry. I will at least pull the latest from github and run setup.py to see what happens. I’m on 10.9 now, so who knows!

thanks, -steve

On Apr 9, 2014, at 12:03 PM, BruceSherwood notifications@github.com wrote:

I'm reluctant to execute this pull request without further discussion for fear of breaking the existing machinery which, with Python from python.org, does build on OSX 10.8. This is quite puzzling.

Bruce

On Tue, Apr 8, 2014 at 11:29 PM, April Arcus notifications@github.comwrote:

You can merge this Pull Request by running

git pull https://github.com/AprilArcus/vpython-wx master

Or view, comment on, or merge it at:

https://github.com/BruceSherwood/vpython-wx/pull/48 Commit Summary

File Changes

  • M include/GL/glext.hhttps://github.com/BruceSherwood/vpython-wx/pull/48/files#diff-0(8)
  • M include/util/shader_program.hpphttps://github.com/BruceSherwood/vpython-wx/pull/48/files#diff-1(4)
  • M src/core/util/shader_program.cpphttps://github.com/BruceSherwood/vpython-wx/pull/48/files#diff-2(18)

Patch Links:

Reply to this email directly or view it on GitHubhttps://github.com/BruceSherwood/vpython-wx/pull/48 .

— Reply to this email directly or view it on GitHub.

mwcraig commented 10 years ago

I spent some time today taking a look at this....and it looks like both @AprilArcus and @sspickle are right:

I spent some time trying to figure out why this latter point was the case...and have absolutely no idea.

To be safe I'd recommend changing the #ifdef to __MAC_10_9 as it doesn't seem to be an issue before 10.9

The change @AprilArcus made was necessary for me to build the anaconda package on 10.9.

AprilArcus commented 10 years ago

Thanks for following up on this. I've updated the #ifdef in my pull request to __MAC_10_9.

AprilArcus commented 10 years ago

pinging Bruce -- are you ready to accept this pull request?

sspickle commented 10 years ago

It's my fault. I've been swamped with finals and end of semester tasks. I will definitely look into it this week. Sorry for the delay.

thanks, -steve

On May 3, 2014, at 3:03 AM, April Arcus notifications@github.com wrote:

pinging Bruce -- are you ready to accept this pull request?

— Reply to this email directly or view it on GitHub.

sspickle commented 10 years ago

Hmm I'm testing it now. I'm on Mavericks, gcc-4.2 getting:

/Users/user/Development/vpython-wx/include/GL/glext.h:3404: error: conflicting declaration ‘typedef ptrdiff_t GLintptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:69: error: ‘GLintptrARB’ has a previous declaration as ‘typedef long int GLintptrARB’ /Users/user/Development/vpython-wx/include/GL/glext.h:3405: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:70: error: ‘GLsizeiptrARB’ has a previous declaration as ‘typedef long int GLsizeiptrARB’

gltypes.h defines GLsizeiptrARB as a simple 'long' not a 'long int'. Not sure what the difference is, I would assume 'long' means 'long int'.

ifndef GL_ARB_vertex_buffer_object

typedef long GLintptrARB; typedef long GLsizeiptrARB;

endif

If I add the following it compiles without complaint.

ifndef GL_ARB_vertex_buffer_object

/* GL types for handling large vertex buffer objects */

ifdef __MAC_10_9

typedef long GLintptrARB; typedef long GLsizeiptrARB;

else

typedef ptrdiff_t GLintptrARB; typedef ptrdiff_t GLsizeiptrARB;

endif

endif

Would it be better to just include gltypes.h? Is there some reason why that's a bad idea? I'm out of my depth here. I hit some other issues that have prevented me from getting a working binary (too new of a boost version I think). I'll report on that separately.

Also.. what kind of system is doing the travis build? Not a mac I guess, huh?

BruceSherwood commented 10 years ago

Alas, this is out of my depth, too. However, I see no reason not to do whatever lets VPython build.

I have no knowledge of the Travis CI environment. It's an instance of a class that has been puzzling me more and more. I see other developers casually mention that they're using library X or tool Y, and when I look for documentation on X or Y I find nothing that I can understand, starting with no overview that says what X or Y is for! I'm truly mystified. I'm going to ask our computer friends at our Wednesday lunch today about this.

Bruce

On Wed, May 7, 2014 at 8:57 AM, Steve Spicklemire notifications@github.comwrote:

Hmm I'm testing it now. I'm on Mavericks, gcc-4.2 getting:

/Users/user/Development/vpython-wx/include/GL/glext.h:3404: error: conflicting declaration ‘typedef ptrdiff_t GLintptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:69: error: ‘GLintptrARB’ has a previous declaration as ‘typedef long int GLintptrARB’ /Users/user/Development/vpython-wx/include/GL/glext.h:3405: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:70: error: ‘GLsizeiptrARB’ has a previous declaration as ‘typedef long int GLsizeiptrARB’

gltypes.h defines GLsizeiptrARB as a simple 'long' not a 'long int'. Not sure what the difference is, I would assume 'long' means 'long int'.

ifndef GL_ARB_vertex_buffer_object

typedef long GLintptrARB; typedef long GLsizeiptrARB;

endif

If I add the following it compiles without complaint.

ifndef GL_ARB_vertex_buffer_object

/* GL types for handling large vertex buffer objects */

ifdef __MAC_10_9

typedef long GLintptrARB; typedef long GLsizeiptrARB;

else

typedef ptrdiff_t GLintptrARB; typedef ptrdiff_t GLsizeiptrARB;

endif

endif

Would it be better to just include gltypes.h? Is there some reason why that's a bad idea? I'm out of my depth here. I hit some other issues that have prevented me from getting a working binary (too new of a boost version I think). I'll report on that separately.

Also.. what kind of system is doing the travis build? Not a mac I guess, huh?

— Reply to this email directly or view it on GitHubhttps://github.com/BruceSherwood/vpython-wx/pull/48#issuecomment-42437652 .

mwcraig commented 10 years ago

Travis-ci.org builds on Ubuntu 12LTS (may have the version number wrong). travis-ci.com does have macs, I think.

I don't have a real gcc installed on my mac -- just the default compiler that comes with Mavericks. It masquerades as gcc but is really clang.

Would it be better to just include gltypes.h? Is there some reason why that's a bad idea? I'm out of my depth here.

Mine too, but if it builds and runs that seems good enough.

@BruceSherwood -- yeah, it is a little confusing, and the documentation is sparse. The one-line summary of the few that I use is:

jimramberg commented 10 years ago

Any indications when a build will be available for someone to use on Mavericks.? Along with the ARB type conflict mentioned above; there is also a rather frequent warning: "Boost.Signals is no longer being maintained and is now deprecated. Please switch to Boost.Signals2

jimramberg commented 10 years ago

Thanks the program now builds and installs without a problem but when I try to run a simple program like from visual import * I get a segmentation fault 11. Any suggestions on where to go from there? Note that I had already installed via brew: wxpython and boost.
himeko:2.7 ramberg$ otool -L /usr/local/Cellar/boost/1.55.0_2/lib/libboost_python-mt.dylib /usr/local/Cellar/boost/1.55.0_2/lib/libboost_python-mt.dylib: /usr/local/lib/libboost_python-mt.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) himeko:2.7 ramberg$ otool -L /usr/local/Cellar/boost/1.55.0_2/lib/libboost_python.dylib /usr/local/Cellar/boost/1.55.0_2/lib/libboost_python.dylib: /usr/local/lib/libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

sspickle commented 10 years ago

Are you getting any kind of traceback or error message other than seg fault?

thanks, -steve

On Jun 2, 2014, at 3:11 AM, Jim Ramberg notifications@github.com wrote:

Thanks the program now builds and installs without a problem but when I try to run a simple program like from visual import * I get a segmentation fault 11. Any suggestions on where to go from there? Note that I had already installed via brew: wxpython and boost.

— Reply to this email directly or view it on GitHub.

sspickle commented 10 years ago

Hmm. Python is building but I'm getting a problem in vector:

aluminum:vpython-wx steve$ python ~/sitepack/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/examples/bounce.py Traceback (most recent call last): File "/Users/steve/sitepack/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/examples/bounce.py", line 1, in from visual import File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/init.py", line 33, in from visual.visual_all import \ # this statement not included in vis/init.py File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/visual_all.py", line 10, in from visual_common.cvisual import vector ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual_common/cvisual.so, 2): Symbol not found: __ZN5boost6python7objects15function_objectERKNS1_11py_functionERKSt4pairIPKNS0_6detail7keywordES9_E Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual_common/cvisual.so Expected in: flat namespace in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual_common/cvisual.so

It looks like some kind of C++/name_mangled constructor is not being found. I rebuilt boost (1.52) in case that was the trouble. No help.

I doubt it's 'vector' specific, it's just the first thing imported.

-steve

On May 7, 2014, at 11:26 AM, BruceSherwood notifications@github.com wrote:

Alas, this is out of my depth, too. However, I see no reason not to do whatever lets VPython build.

I have no knowledge of the Travis CI environment. It's an instance of a class that has been puzzling me more and more. I see other developers casually mention that they're using library X or tool Y, and when I look for documentation on X or Y I find nothing that I can understand, starting with no overview that says what X or Y is for! I'm truly mystified. I'm going to ask our computer friends at our Wednesday lunch today about this.

Bruce

On Wed, May 7, 2014 at 8:57 AM, Steve Spicklemire notifications@github.comwrote:

Hmm I'm testing it now. I'm on Mavericks, gcc-4.2 getting:

/Users/user/Development/vpython-wx/include/GL/glext.h:3404: error: conflicting declaration ‘typedef ptrdiff_t GLintptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:69: error: ‘GLintptrARB’ has a previous declaration as ‘typedef long int GLintptrARB’ /Users/user/Development/vpython-wx/include/GL/glext.h:3405: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:70: error: ‘GLsizeiptrARB’ has a previous declaration as ‘typedef long int GLsizeiptrARB’

gltypes.h defines GLsizeiptrARB as a simple 'long' not a 'long int'. Not sure what the difference is, I would assume 'long' means 'long int'.

ifndef GL_ARB_vertex_buffer_object

typedef long GLintptrARB; typedef long GLsizeiptrARB;

endif

If I add the following it compiles without complaint.

ifndef GL_ARB_vertex_buffer_object

/* GL types for handling large vertex buffer objects */

ifdef __MAC_10_9

typedef long GLintptrARB; typedef long GLsizeiptrARB;

else

typedef ptrdiff_t GLintptrARB; typedef ptrdiff_t GLsizeiptrARB;

endif

endif

Would it be better to just include gltypes.h? Is there some reason why that's a bad idea? I'm out of my depth here. I hit some other issues that have prevented me from getting a working binary (too new of a boost version I think). I'll report on that separately.

Also.. what kind of system is doing the travis build? Not a mac I guess, huh?

— Reply to this email directly or view it on GitHubhttps://github.com/BruceSherwood/vpython-wx/pull/48#issuecomment-42437652 .

— Reply to this email directly or view it on GitHub.

sspickle commented 10 years ago

I rebuilt everything with boost-1.55 and (other than seeing the signals2 deprecation message now) I get the same result.

I'll try to build some simple boost.python examples and ask on the boost forum if I see the same trouble there.

-steve

On Jun 2, 2014, at 5:39 AM, Steve Spicklemire steve@spvi.com wrote:

Hmm. Python is building but I'm getting a problem in vector:

aluminum:vpython-wx steve$ python ~/sitepack/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/examples/bounce.py Traceback (most recent call last): File "/Users/steve/sitepack/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/examples/bounce.py", line 1, in from visual import File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/init.py", line 33, in from visual.visual_all import \ # this statement not included in vis/init.py File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual/visual_all.py", line 10, in from visual_common.cvisual import vector ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual_common/cvisual.so, 2): Symbol not found: __ZN5boost6python7objects15function_objectERKNS1_11py_functionERKSt4pairIPKNS0_6detail7keywordES9_E Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual_common/cvisual.so Expected in: flat namespace in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.6-intel.egg/visual_common/cvisual.so

It looks like some kind of C++/name_mangled constructor is not being found. I rebuilt boost (1.52) in case that was the trouble. No help.

I doubt it's 'vector' specific, it's just the first thing imported.

-steve

On May 7, 2014, at 11:26 AM, BruceSherwood notifications@github.com wrote:

Alas, this is out of my depth, too. However, I see no reason not to do whatever lets VPython build.

I have no knowledge of the Travis CI environment. It's an instance of a class that has been puzzling me more and more. I see other developers casually mention that they're using library X or tool Y, and when I look for documentation on X or Y I find nothing that I can understand, starting with no overview that says what X or Y is for! I'm truly mystified. I'm going to ask our computer friends at our Wednesday lunch today about this.

Bruce

On Wed, May 7, 2014 at 8:57 AM, Steve Spicklemire notifications@github.comwrote:

Hmm I'm testing it now. I'm on Mavericks, gcc-4.2 getting:

/Users/user/Development/vpython-wx/include/GL/glext.h:3404: error: conflicting declaration ‘typedef ptrdiff_t GLintptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:69: error: ‘GLintptrARB’ has a previous declaration as ‘typedef long int GLintptrARB’ /Users/user/Development/vpython-wx/include/GL/glext.h:3405: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptrARB’ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:70: error: ‘GLsizeiptrARB’ has a previous declaration as ‘typedef long int GLsizeiptrARB’

gltypes.h defines GLsizeiptrARB as a simple 'long' not a 'long int'. Not sure what the difference is, I would assume 'long' means 'long int'.

ifndef GL_ARB_vertex_buffer_object

typedef long GLintptrARB; typedef long GLsizeiptrARB;

endif

If I add the following it compiles without complaint.

ifndef GL_ARB_vertex_buffer_object

/* GL types for handling large vertex buffer objects */

ifdef __MAC_10_9

typedef long GLintptrARB; typedef long GLsizeiptrARB;

else

typedef ptrdiff_t GLintptrARB; typedef ptrdiff_t GLsizeiptrARB;

endif

endif

Would it be better to just include gltypes.h? Is there some reason why that's a bad idea? I'm out of my depth here. I hit some other issues that have prevented me from getting a working binary (too new of a boost version I think). I'll report on that separately.

Also.. what kind of system is doing the travis build? Not a mac I guess, huh?

— Reply to this email directly or view it on GitHubhttps://github.com/BruceSherwood/vpython-wx/pull/48#issuecomment-42437652 .

— Reply to this email directly or view it on GitHub.

jimramberg commented 10 years ago

Process: Python [67714] Path: /usr/local/Cellar/python/2.7.7/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: 2.7.7 (2.7.7) Code Type: X86-64 (Native) Parent Process: bash [33535] Responsible: Terminal [33161] User ID: 501

Date/Time: 2014-06-02 09:10:17.716 -0700 OS Version: Mac OS X 10.9.3 (13D65) Report Version: 11 Anonymous UUID: 6F01E679-E034-617D-F64E-E646EB81BB28

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0: --> __TEXT 0000000105510000-0000000105512000 [ 8K] r-x/rwx SM=COW /usr/local/Cellar/python/2.7.7/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.python.python 0x0000000105cfb13d PyInt_FromLong + 33 1 cvisual.so 0x00000001059285a8 boost::python::detail::keywords<1ul>& boost::python::detail::keywords<1ul>::operator=(int const&) + 24 (builtin_converters.hpp:122) 2 cvisual.so 0x000000010592067f cvisual::wrap_arrayobjects() + 3215 (wrap_arrayobjects.cpp:117) 3 cvisual.so 0x00000001058dcba6 cvisual::init_module_cvisual() + 534 (cvisualmodule.cpp:166) 4 libboost_python.dylib 0x0000000105e3bc51 boost::python::handle_exception_impl(boost::function0) + 81 5 libboost_python.dylib 0x0000000105e3cbf6 boost::python::detail::initmodule(char const, void (_)()) + 118 6 org.python.python 0x00000001055b2ffa _PyImport_LoadDynamicModule + 140 7 org.python.python 0x00000001055b2d07 import_submodule + 274 8 org.python.python 0x00000001055b28d1 load_next + 280 9 org.python.python 0x00000001055b08c0 PyImport_ImportModuleLevel + 645 10 org.python.python 0x00000001055962ec builtin_import + 135 11 org.python.python 0x0000000105521ac7 PyObject_Call + 99 12 org.python.python 0x00000001055a0afb PyEval_CallObjectWithKeywords + 93 13 org.python.python 0x000000010559d318 PyEval_EvalFrameEx + 9321 14 org.python.python 0x000000010559ad1e PyEval_EvalCodeEx + 1608 15 org.python.python 0x000000010559a6d0 PyEval_EvalCode + 54 16 org.python.python 0x00000001055af575 PyImport_ExecCodeModuleEx + 236 17 org.python.python 0x00000001055b2122 load_source_module + 813 18 org.python.python 0x00000001055b2d07 import_submodule + 274 19 org.python.python 0x00000001055b28d1 load_next + 280 20 org.python.python 0x00000001055b08c0 PyImportImportModuleLevel + 645 21 org.python.python 0x00000001055962ec builtinimport__ + 135 22 org.python.python 0x0000000105521ac7 PyObject_Call + 99 23 org.python.python 0x00000001055a0afb PyEval_CallObjectWithKeywords + 93 24 org.python.python 0x000000010559d318 PyEval_EvalFrameEx + 9321 25 org.python.python 0x000000010559ad1e PyEval_EvalCodeEx + 1608 26 org.python.python 0x000000010559a6d0 PyEval_EvalCode + 54 27 org.python.python 0x00000001055af575 PyImport_ExecCodeModuleEx + 236 28 org.python.python 0x00000001055b2122 load_source_module + 813 29 org.python.python 0x00000001055b2527 load_package + 303 30 org.python.python 0x00000001055b2d07 import_submodule + 274 31 org.python.python 0x00000001055b28d1 load_next + 280 32 org.python.python 0x00000001055b0888 PyImportImportModuleLevel + 589 33 org.python.python 0x00000001055962ec builtinimport__ + 135 34 org.python.python 0x0000000105521ac7 PyObject_Call + 99 35 org.python.python 0x00000001055a0afb PyEval_CallObjectWithKeywords + 93 36 org.python.python 0x000000010559d318 PyEval_EvalFrameEx + 9321 37 org.python.python 0x000000010559ad1e PyEval_EvalCodeEx + 1608 38 org.python.python 0x000000010559a6d0 PyEval_EvalCode + 54 39 org.python.python 0x00000001055ba4e4 run_mod + 53 40 org.python.python 0x00000001055ba300 PyRun_InteractiveOneFlags + 353 41 org.python.python 0x00000001055b9e0f PyRun_InteractiveLoopFlags + 192 42 org.python.python 0x00000001055b9cbb PyRun_AnyFileExFlags + 60 43 org.python.python 0x00000001055cb672 Py_Main + 2970 44 libdyld.dylib 0x00007fff9425b5fd start + 1

mwcraig commented 10 years ago

@jimramberg -- I'm curious...do you have a brew formula you are building from?

jimramberg commented 10 years ago

The one brew formula that I found (https://gist.github.com/guitorri/3340522) before I found this software fails in the dependency phase: gtkglextmm will not compile and the brew masters even committed this formula to the boneyard due to its lack of active maintainers. I am hoping it does not become an issue down the line

jimramberg commented 10 years ago

I did some playing today and I have found the same crash being reported elsewhere. They claim its a case of having some libs python 2.5 and others 2.7. I. I have no 2.5 residing on my system and have built boost from source. Building though for universal is broken and is a known issue. What exactly does --universal do ?

jimramberg commented 10 years ago

Thought this be useful

from visual import * import visual # directory /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual

/usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual/init.pyc matches /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual/init.py

import visual # precompiled from /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual/init.pyc

/usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/future.pyc matches /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/future.py

import future # precompiled from /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/future.pyc

/usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual/visual_all.pyc matches /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual/visual_all.py

import visual.visual_all # precompiled from /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual/visual_all.pyc import visual_common # directory /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual_common

/usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual_common/init.pyc matches /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual_common/init.py

import visual_common # precompiled from /usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual_common/init.pyc dlopen("/usr/local/Cellar/python/2.7.7_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.05-py2.7-macosx-10.9-x86_64.egg/visual_common/cvisual.so", 2); Segmentation fault: 11

mwcraig commented 10 years ago

@jimramberg -- could you send the commands you are using to build? I have homebrew + mavericks and can try building it here. If you aren't using a homebrew formula to build it is conceivable it is linking into apple's python.

jimramberg commented 10 years ago

Based what I read online; this is what I am using to build boost brew install boost --build-from-source --c++11 --with-python

mwcraig commented 10 years ago

and then

python setup.py install

to build vpython?

jimramberg commented 10 years ago

correct . Note that the build of boost will take 1+ hour

jimramberg commented 10 years ago

Did something else change of late: I just grabbed a new zip and am finding it wouldn't build again /Users/ramberg/Downloads/vpython-wx-master-3/include/GL/glext.h:3404:19: error: typedef redefinition with different types ('ptrdiff_t' (aka 'int') vs 'long') typedef ptrdiff_t GLintptrARB; ^ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:69:14: note: previous definition is here typedef long GLintptrARB; ^

/Users/ramberg/Downloads/vpython-wx-master-3/include/GL/glext.h:3405:19: error: typedef redefinition with different types ('ptrdiff_t' (aka 'int') vs 'long') typedef ptrdiff_t GLsizeiptrARB; ^ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:70:14: note: previous definition is here typedef long GLsizeiptrARB;

sspickle commented 10 years ago

Hi Jim,

This was from a merged pull request from last week or so. I was able to get the python.org python to work with the following change but I'm not sure if it's really a 10.9 thing or if needs to be applied more broadly. I'm building the brew version now...

-steve

diff --git a/include/GL/glext.h b/include/GL/glext.h index 071e18b..d642b5d 100644 --- a/include/GL/glext.h +++ b/include/GL/glext.h @@ -3399,11 +3399,16 @@ typedef ptrdiff_t GLsizeiptr;

endif

endif

-#ifndef GL_ARB_vertex_bufferobject -/* GL types for handling large vertex buffer objects / -typedef ptrdiff_t GLintptrARB; -typedef ptrdiff_t GLsizeiptrARB; -#endif +#ifndef GL_ARB_vertex_bufferobject ^M +/ GL types for handling large vertex buffer objects */ ^M +#ifdef __MAC_10_9 ^M +typedef long GLintptrARB; ^M +typedef long GLsizeiptrARB; ^M +#else ^M +typedef ptrdiff_t GLintptrARB; ^M +typedef ptrdiff_t GLsizeiptrARB; ^M +#endif ^M +#endif ^M

ifndef GL_ARB_shader_objects

/* GL types for handling shader object handles and program/shader text */

On Jun 3, 2014, at 10:35 PM, Jim Ramberg notifications@github.com wrote:

Did something else change of late: I just grabbed a new zip and am finding it wouldn't build again /Users/ramberg/Downloads/vpython-wx-master-3/include/GL/glext.h:3404:19: error: typedef redefinition with different types ('ptrdiff_t' (aka 'int') vs 'long') typedef ptrdiff_t GLintptrARB; ^ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:69:14: note: previous definition is here typedef long GLintptrARB; ^

/Users/ramberg/Downloads/vpython-wx-master-3/include/GL/glext.h:3405:19: error: typedef redefinition with different types ('ptrdiff_t' (aka 'int') vs 'long') typedef ptrdiff_t GLsizeiptrARB; ^ /System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:70:14: note: previous definition is here typedef long GLsizeiptrARB;

— Reply to this email directly or view it on GitHub.

sspickle commented 10 years ago

Did you make manual links to this boost in vpython-wx/dependencies/boost_files?

thanks, -steve

On Jun 3, 2014, at 10:26 PM, Jim Ramberg notifications@github.com wrote:

Based what I read online; this is what I am using to build boost brew install boost --build-from-source --c++11 --with-python

— Reply to this email directly or view it on GitHub.

jimramberg commented 10 years ago

That was another thing that I found curious. I did not setup the links and it still built. BTW ; at least for me; I am seeing a new compile time issue dealing with typedef conflicts again so I don't expect that you will get very far in the build process. The variables in question this time are: GLinptrARB & GLsizeiptrARB

AprilArcus commented 10 years ago

Thank you for merging my pull request. Please open a new issue for Boost errors.