BruceSherwood/vpython-wx

OpenGL typedef redefinition issues: GLintptrARB and GLsizeiptrARB

jimramberg opened this issue · 12 comments

Similar to what was reported before:
/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;

and
/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;

I am running OSX under Mavericks and using homebrew

For easy cross-reference: earlier discussion of this is in #48

Update on brewing....on a freshly created VM running OS 10.9.3 I do not get this compilation error.

My guess is that you are also using a brew-installed compiler (gcc of some flavor?) and I'm using clang (in 10.9 even the apple-provided gcc is really clang).

I made a little progress in compiling against homebrew...the initial seg fault you were getting is because the -framework Python option in setup.py causes a link to the system-installed python but you were running it with a brew-installed python (see https://github.com/Homebrew/homebrew/wiki/Common-Issues).

I fixed up the linking and got to the point that I could import visual....but doing anything with it, like visual.sphere() caused a seg fault.

My guess is that the linking is still not quite correct, likely in brew's wxmac or wxpython, but I don't have time to chase it down right now, and won't for a little while.

What is your goal @jimramberg? Is it to be able to use vpython without installing python.org because that will interfere with the brew python? If so, anaconda might work for you (actually, I'd recommend miniconda).

Pinging @sspickle so he is aware of this.

What would eventually be nice here is a brew formula (I know how to make these) for vpython. There is an outside chance that simply building inside a formula would fix this, but if I start up the VM I'm using for this again, I won't come out for hours :).

Thanks for the advice. I will look into anaconda

A couple bits of advice about anaconda + brew python + system python:

  • If you want to keep brew python as your primary python be sure to not let it modify your path and/or set anaconda as your default python when you install.
  • Assuming you don't let it install as the default, put this at the front of your path when you want to use anaconda: ~/anaconda/bin (as in export PATH=~/anaconda/bin:$PATH)

Once you have anaconda, installing visual is easy (shameless self-promotion here):

conda install -c mwcraig vpython

When I'm at scipy later this summer I'm going to lobby for getting the vpython package included in one of the default conda channels so that the -c mwcraig won't be necessary.

What does this mean ?
This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.

Never mind : figured it out need to run in spider

Oops, should have added that you can run from the command line with pythonw—
Sent from Mailbox

On Thu, Jun 5, 2014 at 3:03 PM, Jim Ramberg notifications@github.com
wrote:

Never mind : figured it out need to run in spider

Reply to this email directly or view it on GitHub:
#59 (comment)

will that work at the shebang (#!) level ?

Not sure, but I think it should -- in anaconda pythonw is a link into a python app that functions essentially as a framework. —
Sent from Mailbox

On Thu, Jun 5, 2014 at 3:18 PM, Jim Ramberg notifications@github.com
wrote:

will that work at the shebang (#!) level ?

Reply to this email directly or view it on GitHub:
#59 (comment)

I also got the brew version to compile but ended up with the same segfault. Maddening!

thanks,
-steve

On Jun 5, 2014, at 12:21 PM, Matt Craig notifications@github.com wrote:

Update on brewing....on a freshly created VM running OS 10.9.3 I do not get this compilation error.

My guess is that you are also using a brew-installed compiler (gcc of some flavor?) and I'm using clang (in 10.9 even the apple-provided gcc is really clang).

I made a little progress in compiling against homebrew...the initial seg fault you were getting is because the -framework Python option in setup.py causes a link to the system-installed python but you were running it with a brew-installed python (see https://github.com/Homebrew/homebrew/wiki/Common-Issues).

I fixed up the linking and got to the point that I could import visual....but doing anything with it, like visual.sphere() caused a seg fault.

My guess is that the linking is still not quite correct, likely in brew's wxmac or wxpython, but I don't have time to chase it down right now, and won't for a little while.

What is your goal @jimramberg? Is it to be able to use vpython without installing python.org because that will interfere with the brew python? If so, anaconda might work for you (actually, I'd recommend miniconda).

Pinging @sspickle so he is aware of this.

What would eventually be nice here is a brew formula (I know how to make these) for vpython. There is an outside chance that simply building inside a formula would fix this, but if I start up the VM I'm using for this again, I won't come out for hours :).


Reply to this email directly or view it on GitHub.

I agree its maddening . For now at least anaconda allows me to be able to do what I wanted to do in the first place and does not totally screw up my brew build environment in the process ( which is what attempting to install the mac binary did) . Based on what I worked on yesterday; I am pretty sure that that boost that is built by brew won't be suppling what is needed for vpython to build right (i.e. the stand make target).
The seg fault 11 issue:
I though that since I had python 2.7 in both /usr and /usr/local that I should not have any build issues dealing with python conflicts but I guess I was wrong there.

/usr/local/bin/python
Python 2.7.7 (default, Jun 3 2014, 15:08:24)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

himeko:Three_Body ramberg$ /usr/bin/python
Python 2.7.5 (default, Mar 9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin

Please refresh your checkout and rebuild. I think this one is solved.