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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

 
On Tuesday, October 09, 2007, at 12:29PM, "Greg
Ewing" <greg.ewingcanterbury.ac.nz>
wrote:
>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-Devpython.org
>ht
tp://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe: http://mail.python.org/mailman/options
/python-dev/ronaldoussoren%40mac.com
>
>
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.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


_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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
>
>


_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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-Devpython.org
> ht
tp://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/option
s/python-dev/graham.horler%40gmail.com
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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/           
phdphd.pp.ru
           Programmers don't die, they just GOSUB without
RETURN.
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Oleg Broytmann wrote:
>    Do you have a few different copies of gcc installed
with setup.py called
> the wrong one and your shell script the right one?

As far as I can tell, it's using my PATH to find gcc,
and that leads to /usr/bin/gcc, which is the same one
my wrapper calls.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

I wrote:

> As far as I can tell, it's using my PATH to find gcc,
> and that leads to /usr/bin/gcc, which is the same one
> my wrapper calls.

To make sure, I installed my wrapper in place of
/usr/bin/gcc
and the same behaviour occurs.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com