command
interpreter.
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
ight get away with only some 64 bit libraries, but I am
not an expert on X.
Is it really worth all the hassle when Leopard is going to be out in
a few months??
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail
E you end up with a mass of old temporary files - the standard
Windows curse.
Apple seem to have adopted a convention of using /tmp/UID. I think
the idea is that these are cleaned when the user logs out. So a full
restart is not needed to
On 09/02/2006, at 5:44 PM, Ronald Oussoren wrote:
>
> This has nothing to do with C++ vs. C, but that Carbon/Carbon.h is
> not POSIX compliant (and that's likely also true for other Apple
> headers).
Why do you say it is not POSIX compliant? As my test program
demonstrates, it works correct
me from source and it
runs Bob's demo programs. without recompiling them.
Cheers
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
If you try to build wxWidgets from the wxPython 2.6.2.1 sources with
'--enable-optimize --disable-debug', configure creates setup.h in a
release directory but the Makefile looks for it in a debug directory.
Whoops!
Maybe this is related to the problem with the monolithic bu
On 09/02/2006, at 5:45 AM, Ronald Oussoren wrote:
>> #define _POSIX_C_SOURCE 200112L
>> #include
>> int main ()
>> {
>> }
>
> Is that a valid POSIX program? Don't define _POSIX_C_SOURCE if you use
> system libraries that are not part of POSIX.
It is valid if somewhat minimal program in both
right approach is to wrap them
in '#if !defined(__cplusplus).
Nothing I have seen so far provides any evidence to contradict
Apple's assertion that Tiger is POSIX compliant.
Cheers
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@
changes the cvs code for PyOpenGL builds happily, although
there are still a lot of warnings.
Thanks
Bill Northcott
PS This build works happily with _POSIX_C_SOURCES defined!
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
>> I quite agree that it would be best to have a solution guaranteed
>> to work in the future. However, the standard makes it very clear
>> that these sort of behaviours may change in the future. So it not
>> possible to use something like _XOPEN_SOURCE >= 600 with any
>> confidence.
>
>
On 04/02/2006, at 12:51 PM, Bob Ippolito wrote:
> All this POSIX compliance stuff was broken on Mac OS X 10.2, then
> Apple 'fixed' it in 10.3, but it regressed in 10.4
From what I have seen on the particular issue of strcasecmp(), that
is backwards. The headers were non-compliant in 10.3 an
On 04/02/2006, at 12:00 PM, Bob Ippolito wrote:
>> The issue only arises using Python 2.4.x on Tiger. It does not arise
>> with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS 10.3.x)
>
> On top of that, it should only happen if you're using a Python
> 2.4.x build on Tiger that was compi
on framework built for 10.3. However, I need wxPython, so I'm
> interested in this thread.
>
> Bill Northcott wrote:
> > I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77)
> > with some difficulty, which may just be me being dense.
>
> Is this only
Hi Kevin
On 04/02/2006, at 11:08 AM, Kevin Ollivier wrote:
>> As I read the Opengroup document, Posix 200112L and Xopen 600 have
>> been converged. Older standards would not be the same and
>> certainly older versions of Xopen might have strcasecmp and
>> friends in string.h. OTOH higher v
>> PS I still have the issue from my other posting which Adriano
>> posted in September.
>
> Could you give me a thread to look up so that I can follow up?
I spent a bit more time on this, but I have to quit now.
The problem here is that if is included with _POSIX_C_SOURCE
defined, the gamm
On 04/02/2006, at 3:52 AM, Kevin Ollivier wrote:
>> So I added more alternative conditions to wx/string.h:46 thus:
>> #if defined(HAVE_STRCASECMP_IN_STRINGS_H) || _POSIX_C_SOURCE ==
>> 200112L || _XOPEN_SOURCE == 600
>>
>> This definitely works on MacOS X 10.4 and I don't see how it can
>> brea
200112L || _XOPEN_SOURCE == 600
This definitely works on MacOS X 10.4 and I don't see how it can
break on other systems.
Cheers
Bill Northcott
PS I still have the issue from my other posting which Adriano posted
in September.
___
Pythonmac-SIG
int roundtoll
(long double)':
/System/Library/Frameworks/CoreServices.framework/Frameworks/
CarbonCore.framework/Headers/fp.h:2179: error: 'roundtol' was not
declared in this scope
error: command 'gcc' failed with exit status 1
I am trying to build wxPython 2.6.2 with
The more I look, the more the problem spreads.
I found that _POSIX_C_SOURCES is defined in pyconfig.h in Python 2.4
but not 2.3. So this problem will only arise using Python 2.4 on
Tiger. Python 2.4 on Panther, or 2.3 on Tiger would be OK. It seems
both Apple and the Python people decided
new
seems to me to be correct, as in standards compliant. I have seen
similar on Tru64 and Solaris, and seen similar problems arise.
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo
something that I am doing wrong or does this need fixing?
If someone could give me some pointers about exactly how the
wxWidgets configuration propagates down to wxPython, then I might be
able to cook up some sort of fix. Also does anyone understand when
and
without a load of questionable
binaries.
The version of python you use will be the one which comes first in
your PATH. Try 'which python' which will tell you. Apple puts
symlinks in /usr/bin. If your home built/otherwise obtained Python
comes before /usr/bin in the PATH it
On 12/08/2005, at 4:26 AM, Samuel M.Smith wrote:
> And now setup.py build still exits with an error in the same place
> but the error is different
>
> collect2: ld returned 1 exit status
> /usr/bin/ld: Undefined symbols:
> _fprintf$LDBLStub
> _sprintf$LDBLStub
> collect2: ld returned 1 exit statu
r some other web site would
document this issue. I must have posted at least twenty messages
saying the same thing.
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
On 25/07/2005, at 10:46 AM, Bob Ippolito wrote:
> The fix was simply to get it to compile, and was done way before
> the x86 transition. Changing the build process is a PITA and you
> have to be careful not to cause issues with other platforms and
> previous versions of OS X.
>
> Patches ac
On 24/07/2005, at 4:20 PM, Bob Ippolito wrote:
>
> I fixed this problem for 2.4.1 (CVS HEAD should be fine too). I
> don't really consider 2.3 important enough to spend my time
> backporting. If you notice, Apple didn't compile Python 2.3 under
> gcc 4 either.
I got a chance to look at the
On 24/07/2005, at 4:20 PM, Bob Ippolito wrote:
> I fixed this problem for 2.4.1 (CVS HEAD should be fine too). I
> don't really consider 2.3 important enough to spend my time
> backporting. If you notice, Apple didn't compile Python 2.3 under
> gcc 4 either.
Great. As long as its fixed th
On 24/07/2005, at 4:01 PM, Bob Ippolito wrote:
>> I am trying to build Python 2.3.5 sources on MacOS X 10.4.2 using
>> gcc-4.
>>
>
> I think you should try it with gcc 3.3 instead.
I am well aware that it work better with gcc-3.3. However, gcc-4 is
the default compiler for Tiger and the Makef
'make
frameworkinstall'. The framework appears to have built correctly.
Bill Northcott
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
29 matches
Mail list logo
