pygame is sharing code with you

Bitbucket is a code hosting site. Unlimited public and private repositories. Free for small teams.

Don't show this again

pygame / pygame http://pygame.org/

Clone this repository (size: 15.4 MB): HTTPS / SSH 
hg clone https://bitbucket.org/pygame/pygame
hg clone ssh://hg@bitbucket.org/pygame/pygame

Issues

#103 Problem installing with Homebrew/pip on OS X Lion

Reported by dronir (last edited )

Trying in install Pygame on Lion, following the instructions from illume here: https://bitbucket.org/pygame/pygame/issue/82/homebrew-on-leopard-fails-to-install

I have the homebrew installation of Python as my default one. 

$ which python
/usr/local/bin/python

Using the following commands:

brew install sdl sdl_image sdl_mixer sdl_ttf smpeg portmidi 
pip install hg+http://bitbucket.org/pygame/pygame

(First of all portmidi fails to install from homebrew because a hash discrepancy, but I disregarded this for now.)

When building Pygame, I get warnings of the following kind:

building 'pygame.mixer' extension

/usr/bin/llvm-gcc -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -O3 -w -pipe -march=core2 -msse4.1 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Ddarwin -D_THREAD_SAFE -I/usr/X11R6/include -I/usr/local/include/SDL -I/usr/local/include/SDL -I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/mixer.c -o build/temp.macosx-10.5-intel-2.7/src/mixer.o

/usr/bin/llvm-gcc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot / -L/usr/local/Cellar/readline/6.2.2/lib build/temp.macosx-10.5-intel-2.7/src/mixer.o -L/usr/local/lib -L/usr/local/lib -lSDLmain -lSDL -lSDL_mixer -o build/lib.macosx-10.5-intel-2.7/pygame/mixer.so -Wl,-framework,Cocoa

ld: warning: ignoring file /usr/local/lib/libSDLmain.a, file was built for archive which is not 
the architecture being linked (i386)

ld: warning: ignoring file /usr/local/lib/libSDL.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

ld: warning: ignoring file /usr/local/lib/libSDL_mixer.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

This happens to all extensions using SDL. Pygame does build despite the warnings, but functionality is lost. Spent a while with Google trying to figure out what to do about it, but couldn't find any solution.

Edit: separated the output lines for legibility.

Status: open Responsible: nobody Type: bug Priority: major
Milestone: none Component: SDL Version: Development

Attachments

No attachments added for this issue yet.

Comments and changes

  1. #1 dronir

    written

    • Changed content.
  2. #2 illume

    written

    • Changed status from new to open.

    Hi,

    it looks like your architechture is not i386... but it is building pygame for i386...

    I wonder what your architecture is for sdl? I am guessing it is x86_64 only.

    lipo -info /usr/local/lib/libSDL.dylib

    Perhaps try this before compiling pygame?

    export CFLAGS='-isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64'
  3. #3 dronir

    written

    The SDL architecture is indeed x86_64.

    $ lipo -info /usr/local/lib/libSDL.dylib
Non-fat file: /usr/local/lib/libSDL.dylib is architecture: x86_64

    Unfortunately that line you suggest does not work. Not only do I still get the same warnings as before, but additionally I get lots of these warnings:

    In file included from /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:126,
                 from src/pygame.h:80,
                 from src/mixer.c:27:
/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/include/python2.7/modsupport.h:27: warning: ‘PyArg_ParseTuple’ is an unrecognized format function type

    I'm actually now even more interested in this problem, because I encountered the same problem at work, trying to build an otherwise unrelated Python module written in C that my coworker wrote.

  4. #4 dronir

    written

    I wonder if this is related to the issue that uname -p returns i386 on OS X for some reason, even if it's a x86_64 system. At the same time uname -m does return x86_64.

  5. #5 dronir

    written

    Ok, I finally managed to build it. This worked:

    export ARCHFLAGS='-arch x86_64'

    Now everything seems to work as it should.

Add comment / attachment

Verification: Please write the text from the image in the box (letters only)

captcha

Is that you, Humanoid? Is this me?