On Feb 8, 2006, at 12:42 PM, Ronald Oussoren wrote:
>
> On 8-feb-2006, at 21:21, Bob Ippolito wrote:
>
>>
>> On Feb 8, 2006, at 11:59 AM, Ronald Oussoren wrote:
>>
>>>
>>> On 7-feb-2006, at 0:59, Bob Ippolito wrote:
>>>>>
>>>>> Bob, what do you think the timescale is for a universal build?
>>>>> If it's
>>>>> soon, then we should work on re-0writing the web site as though
>>>>> it's
>>>>> ready to go.
>>>>
>>>> I'd say soon... The only issues left are to sort out the
>>>> distribution
>>>> scripts and some more testing I guess.
>>>
>>> Having a working build environment would also be nice. 'make
>>> frameworkinstall'
>>> fails if builddir != srcdir. I'm working on this right now.
>>
>> It worked for me.. I never build in srcdir. What's the problem?
>
> $make frameworkinstall
> ...
> gcc -arch ppc -arch i386 -isysroot / -fno-strict-aliasing -Wno-
> long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
> DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Include -c -o
> Mac/OSX/PythonLauncher/main.o ../Mac/OSX/PythonLauncher/main.m
> lipo: can't create output file: Mac/OSX/PythonLauncher/main.o (No
> such file or directory)
>
>
> svn diff says that everything is fine. Maybe it's because I'm
> building a DTK system and I haven't bothered upgrading it because
> I'm running headless and didn't have a screen lying around when
> update came in.
Doesn't your Makefile.pre.in have this?
Mac/OSX/PythonLauncher:
mkdir -p $@
PythonLauncher: $(LIBRARY) Mac/OSX/PythonLauncher $(PYTHONLAUNCHER_OBJS)
> Anyway, don't like your solution for building PythonLauncher. I've
> replaced it by a Makefile.in in Mac/OSX/PythonLauncher, that way
> all logic for building
> PythonLauncher is nicely located in the Mac/OSX/PythonLauncher
> directory. I might rewrite Mac/OSX/Makefile as well now that I'm
> working on this.
I don't like it much either. Please go for it.
>>> BTW. The distribution script is mostly done but I stopped because
>>> I got annoyed by the aformentioned build problems. Hopefully I
>>> can finish it
>>> this week.
>>>
>>> BTW2. Does anyone know why the python is linked using c++? Would
>>> that cause
>>> problems if you build python itself using gcc 4 on Tiger and then
>>> use g++ 3.3
>>> to build extensions on 10.3 (say because you want to build
>>> wxPython)?
>>
>> http://mail.python.org/pipermail/python-dev/2003-July/036775.html
>>
>> """
>> This change was needed to support various C++ compilers that would
>> fail to link Modules/ccpython.cc with the C compiler.
>> """
>>
>> The question then becomes, why does the main program need to be
>> compiled with C++?
>
> That's the same as my question (although I did phrase it very
> awkwardly, use
> s/the python is/the python executable is/ to fix that).
>
> Maybe it is necessary to ensure proper behaviour for C++ extensions
> with global
> variables that have constructors, in which case we'd probably be
> hosed. Does anyone
> has a Python extension that does this lying around (compiled using g
> ++-3 on Panther)?
>
> The 10.3 system I'm testing the universal build on doesn't have a
> compiler installed,
> the only other system with 10.3 is my main machine. I'll have to
> install various flavours
> of 10.3 on an external disk one of these days ;-)
gcc might not be one of those compilers that requires the executable
to be linked with C++. I can't imagine it would have that
restriction, given the amount of frameworks that Apple develops in C+
+ or Objective-C++ and the fact that almost all Cocoa executables are
linked with just gcc...
-bob
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
