MacOSX -framework options and distutils weirdness
A while back I wrote about a problem I was having with the ordering of -framework options in distutils compilation commands. Well, now I've discovered something even stranger. When distutils executes the following link command, I get a bunch of undefined OpenGL-related symbols. But if I copy and paste *exactly the same command* into the shell, it succeeds! What could possibly be going on here? gcc -Wl,-F. -bundle -framework Python build/temp.darwin-8.4.0-Power_Macintosh-2.3/_soya.o build/temp.darwin-8.4.0-Power_Macintosh-2.3/matrix.o build/temp.darwin-8.4.0-Power_Macintosh-2.3/chunk.o -L/usr/lib -L/usr/local/lib -L/usr/X11R6/lib -lm -lGLEW -lfreetype -lcal3d -lstdc++ -lode -o build/lib.darwin-8.4.0-Power_Macintosh-2.3/soya/_soya.so -framework OpenGL -framework SDL -framework OpenAL This is on MacOSX 10.4 with Python 2.3. -- Greg
On Tuesday, October 09, 2007, at 12:29PM, "Greg Ewing"
A while back I wrote about a problem I was having with the ordering of -framework options in distutils compilation commands. Well, now I've discovered something even stranger.
When distutils executes the following link command, I get a bunch of undefined OpenGL-related symbols. But if I copy and paste *exactly the same command* into the shell, it succeeds!
What could possibly be going on here?
My guess is MACOSX_DEPLOYMENT_TARGET: this is set in the environment by distutils.
gcc -Wl,-F. -bundle -framework Python build/temp.darwin-8.4.0-Power_Macintosh-2.3/_soya.o build/temp.darwin-8.4.0-Power_Macintosh-2.3/matrix.o build/temp.darwin-8.4.0-Power_Macintosh-2.3/chunk.o -L/usr/lib -L/usr/local/lib -L/usr/X11R6/lib -lm -lGLEW -lfreetype -lcal3d -lstdc++ -lode -o build/lib.darwin-8.4.0-Power_Macintosh-2.3/soya/_soya.so -framework OpenGL -framework SDL -framework OpenAL
This is on MacOSX 10.4 with Python 2.3.
Is that the system supplied version of Python? Distutils sets MACOSX_DEPLOYMENT_TARGET to 10.4 in that case, for home-build binaries the variable is set to whatever the value was at configure time, defaulting to 10.3. Ronald
-- Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
Ronald Oussoren wrote:
Is that the system supplied version of Python?
No, it's my own installation of 2.3, but it's installed as a framework in /Library/Frameworks.
My guess is MACOSX_DEPLOYMENT_TARGET: this is set in the environment by distutils.
I wondered about that -- I've noticed that with later Python versions, distutils linking commands *don't* work in the shell unless I set MACOSX_DEPLOYMENT_TARGET to 10.3 (it's not set at all in my shell environment by default). But the problem here is the other way around. I would have thought distutils would set it to something appropriate for the Python being used. Any suggestions on how I can find out what setting of MACOSX_DEPLOYMENT_TARGET is being used by distutils, and how to make it use something different if it's not right? -- Greg
On 9 Oct, 2007, at 23:11, Greg Ewing wrote:
Ronald Oussoren wrote:
Is that the system supplied version of Python?
No, it's my own installation of 2.3, but it's installed as a framework in /Library/Frameworks.
My guess is MACOSX_DEPLOYMENT_TARGET: this is set in the environment by distutils.
I wondered about that -- I've noticed that with later Python versions, distutils linking commands *don't* work in the shell unless I set MACOSX_DEPLOYMENT_TARGET to 10.3 (it's not set at all in my shell environment by default).
But the problem here is the other way around. I would have thought distutils would set it to something appropriate for the Python being used.
It is supposed to do that, but to be honest I don't remember if the code for that is present in the 2.3 tree and I'm too lazy to check the sources right now. The deployment target does have an influence on how the compiler functions, which can explain when setting the target to a different value causes problems.
Any suggestions on how I can find out what setting of MACOSX_DEPLOYMENT_TARGET is being used by distutils, and how to make it use something different if it's not right?
In current versions of python this is read from config/Makefile in the standard library (that is /Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/config/Makefile) Ronald
-- Greg
Ronald Oussoren wrote:
The deployment target does have an influence on how the compiler functions, which can explain when setting the target to a different value causes problems.
I did some more experimenting, and it doesn't seem to be related to MACOSX_DEPLOYMENT TARGET. I tried setting it to 10.1, 10.2, 10.3, 10.4 and leaving it unset, and in all these cases the command works when run directly from the shell. So I'm not sure what to try next. -- Greg
I would be inclined to move gcc to gcc-real (for example), and create a script called gcc which dumps all environment variables, and command-line arguments and a time-stamp to /tmp/gcc.<PID>, e.g.: #!/bin/sh FN=/tmp/gcc.$$ echo -n "date=" > $FN date '+%Y/%m/%d %H:%M:%S.%N' >> $FN echo -n "cmdline=" >> $FN echo $0 $@ >> $FN set >> $FN gcc-real "$@" echo "exitcode=$?" >> $FN (I don't know if any of this will be different on OSX, I'm using Linux.) Then run the command manually, and compare the dump files. Here's hoping this helps, Graham On 10 Oct 2007, 12:36:13, Greg Ewing wrote:
Ronald Oussoren wrote:
The deployment target does have an influence on how the compiler functions, which can explain when setting the target to a different value causes problems.
I did some more experimenting, and it doesn't seem to be related to MACOSX_DEPLOYMENT TARGET. I tried setting it to 10.1, 10.2, 10.3, 10.4 and leaving it unset, and in all these cases the command works when run directly from the shell.
So I'm not sure what to try next.
-- Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/graham.horler%40gmail.com
Graham Horler wrote:
I would be inclined to move gcc to gcc-real (for example), and create a script called gcc which dumps all environment variables, and command-line arguments
Well, I tried that -- and things got even weirder still. With the wrapper in place between distutils and gcc, the linking command *worked*. So then I cut the wrapper down so that the only thing it does is call gcc, and it *still* works. Just to make sure, I tried it again without the wrapper, and it failed. So the bizarre state of affairs is that if distutils runs gcc through a shell script, it works, but if it runs gcc directly, it doesn't work. Anyone have any ideas on how that can happen? -- Greg
On Fri, Oct 12, 2007 at 09:21:15PM +1300, Greg Ewing wrote:
So the bizarre state of affairs is that if distutils runs gcc through a shell script, it works, but if it runs gcc directly, it doesn't work.
Anyone have any ideas on how that can happen?
Do you have a few different copies of gcc installed with setup.py called the wrong one and your shell script the right one? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
participants (4)
-
Graham Horler -
Greg Ewing -
Oleg Broytmann -
Ronald Oussoren