Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#19938 closed defect (invalid)

building Python 26 fails

Reported by: nefar@… Owned by: blb@…
Priority: Normal Milestone:
Component: ports Version: 1.7.1
Keywords: 10.5.7 Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Port: python26

Description (last modified by mf2k (Frank Schima))

Also see: #13540

The above bug looks like it had the same issues. I tried reinstalling Xcode, but to no avail. Using 10.5.7

Any help is appreciated.

Command issued: port install mercurial

--->  Building python26
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2" && make all MAKE="make CC=/usr/bin/gcc-4.0" " returned error 2
Command output:                  from Include/pymactoolbox.h:13,
                 from Python/mactoolboxglue.c:27:
/System/Library/Frameworks/CoreVideo.framework/Headers/CVOpenGLBuffer.h:84: error: syntax error before 'CGLContextObj'
In file included from /System/Library/Frameworks/CoreVideo.framework/Headers/CoreVideo.h:29,
                 from /System/Library/Frameworks/QuartzCore.framework/Headers/CoreVideo.h:1,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h:25,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/Movies.h:56,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/MediaHandlers.h:24,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/QuickTime.h:34,
                 from Include/pymactoolbox.h:13,
                 from Python/mactoolboxglue.c:27:
/System/Library/Frameworks/CoreVideo.framework/Headers/CVOpenGLTexture.h:66: error: syntax error before 'CVOpenGLTextureGetTarget'
/System/Library/Frameworks/CoreVideo.framework/Headers/CVOpenGLTexture.h:74: error: syntax error before 'CVOpenGLTextureGetName'
/System/Library/Frameworks/CoreVideo.framework/Headers/CVOpenGLTexture.h:95: error: syntax error before 'GLfloat'
In file included from /System/Library/Frameworks/CoreVideo.framework/Headers/CoreVideo.h:30,
                 from /System/Library/Frameworks/QuartzCore.framework/Headers/CoreVideo.h:1,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h:25,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/Movies.h:56,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/MediaHandlers.h:24,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/QuickTime.h:34,
                 from Include/pymactoolbox.h:13,
                 from Python/mactoolboxglue.c:27:
/System/Library/Frameworks/CoreVideo.framework/Headers/CVOpenGLTextureCache.h:74: error: syntax error before 'CGLContextObj'
In file included from /System/Library/Frameworks/QuickTime.framework/Headers/Movies.h:56,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/MediaHandlers.h:24,
                 from /System/Library/Frameworks/QuickTime.framework/Headers/QuickTime.h:34,
                 from Include/pymactoolbox.h:13,
                 from Python/mactoolboxglue.c:27:
/System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h:12579: error: syntax error before 'CGLContextObj'
make: *** [Python/mactoolboxglue.o] Error 1

Error: The following dependencies failed to build: python26
Error: Status 1 encountered during processing.

Attachments (1)

py26.build.txt (61.1 KB) - added by nefar@… 12 years ago.
build output

Download all attachments as: .zip

Change History (22)

comment:1 Changed 12 years ago by mf2k (Frank Schima)

Cc: mcalhoun@… added
Description: modified (diff)
Owner: changed from macports-tickets@… to blb@…

comment:2 Changed 12 years ago by blb@…

What is the version of Xcode you have installed? You can use xcodebuild -version.

comment:3 in reply to:  2 Changed 12 years ago by nefar@…

$ xcodebuild -version Xcode 3.1.2 Component versions: DevToolsCore-1148.0; DevToolsSupport-1102.0 BuildVersion: 9M2621

comment:4 Changed 12 years ago by blb@…

Okay, older Xcode isn't the problem. Can you rerun with debug:

sudo port clean --work python26
sudo port -d install python26

There may be earlier error messages.

Changed 12 years ago by nefar@…

Attachment: py26.build.txt added

build output

comment:5 Changed 12 years ago by nefar@…

Looks like this is the problem: /System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h:24:27: error: OpenGL/OpenGL.h: No such file or directory

Seems port command should output more info without the -d as far as stack trace. Anyway, any idea why that's missing?

comment:6 Changed 12 years ago by raimue (Rainer Müller)

Most probably you did unselect the OpenGL SDK when installing Xcode Tools. You should install all components.

comment:7 in reply to:  5 Changed 12 years ago by blb@…

Replying to nefar@…:

Seems port command should output more info without the -d as far as stack trace. Anyway, any idea why that's missing?

port only keeps so many lines of output as it's running when debug isn't enabled, so it occasionally happens that the meaningful output precedes those lines. Note that an improved logging system is being worked as as part of this year's GSoC.

comment:8 Changed 12 years ago by nefar@…

I've actually gone back and specifically installed the OpenGL packages by hand since I saw the OpenGL related messages, so that can't be the problem (unless I was dreaming). Any other ideas?

comment:9 Changed 12 years ago by blb@…

Does the file /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/OpenGL.h exist?

comment:10 Changed 12 years ago by nefar@…

Yes, it does. -rw-r--r-- 1 root wheel 5716 Oct 2 2007 /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/OpenGL.h

suspicious date though, at least if it's supposed to have been updated with the latest OpenGL package. is that date correct, or?

comment:11 Changed 12 years ago by blb@…

Actually that file info is identical to mine (date and size). So the file is available but isn't being seen for some reason. Compiling here shows an identical invocation for gcc as yours, so it isn't missing any necessary options. Grabbing at straws a bit, what is the result from running

grep Version /System/Library/Frameworks/QuickTime.framework/Versions/A/Headers/QuickTime.h

comment:12 Changed 12 years ago by nefar@…

Version: QuickTime 7.2.1

MD5 (/System/Library/Frameworks/QuickTime.framework/Versions/A/Headers/QuickTime.h) = e87bda9a59b6da5b788423f338514596

comment:13 Changed 12 years ago by blb@…

Nothing weird yet; how about

ls -l /System/Library/Frameworks/OpenGL.framework

comment:14 Changed 12 years ago by nefar@…

$ ls -l /System/Library/Frameworks/OpenGL.framework
total 736
lrwxr-xr-x   1 root  wheel      94 Jun 12 21:39 CodeResources -> ../../../../../../../../../System/Library/Frameworks/OpenGL.framework/Versions/A/CodeResources
lrwxr-xr-x   1 root  wheel      24 Jun 13 12:38 Headers -> Versions/Current/Headers
drwxr-xr-x@ 10 root  wheel     340 Jun 13 09:57 Libraries
-rwxr-xr-x@  1 root  wheel  364768 Jun 13 09:57 OpenGL
drwxr-xr-x@ 20 root  wheel     680 Jun 13 09:57 Resources
drwxr-xr-x@  5 root  wheel     170 Jun 13 09:57 Versions

comment:15 Changed 12 years ago by blb@…

Okay, now it gets weird; all of those but Versions should be symlinks but are actual files/directories there. Eg on my machine:

lrwxr-xr-x  1 root  wheel   94 May 12 18:27 CodeResources@ -> ../../../../../../../../../System/Library/Frameworks/OpenGL.framework/Versions/A/CodeResources
lrwxr-xr-x  1 root  wheel   24 Apr  2 15:23 Headers@ -> Versions/Current/Headers
lrwxr-xr-x  1 root  wheel   26 Apr  1 17:48 Libraries@ -> Versions/Current/Libraries
lrwxr-xr-x  1 root  wheel   23 Apr  1 17:48 OpenGL@ -> Versions/Current/OpenGL
lrwxr-xr-x  1 root  wheel   26 Apr  1 17:48 Resources@ -> Versions/Current/Resources
drwxr-xr-x  4 root  wheel  136 Apr  1 17:48 Versions/

comment:16 Changed 12 years ago by nefar@…

Ok, there was the problem. The headers file were not present in the Headers folder. I changed my whole directory to look like this. Maybe it wasn't necessary, maybe only changing the Headers link would have been enough, but this is working:

# ls -l
total 48
-rwxr-xr-x  1 root  wheel  4096 Jun 13 09:57 ._Versions
lrwxr-xr-x  1 root  wheel    94 Jun 15 17:17 CodeResources -> ../../../../../../../../../System/Library/Frameworks/OpenGL.framework/Versions/A/CodeResources
lrwxr-xr-x  1 root  wheel    18 Jun 15 17:26 Headers -> Versions/A/Headers
lrwxr-xr-x  1 root  wheel    26 Jun 15 17:19 Libraries -> Versions/Current/Libraries
lrwxr-xr-x  1 root  wheel    23 Jun 15 17:19 OpenGL -> Versions/Current/OpenGL
lrwxr-xr-x  1 root  wheel    26 Jun 15 17:19 Resources -> Versions/Current/Resources
drwxr-xr-x@ 5 root  wheel   170 Jun 13 09:57 Versions

Thanks much for helping. I'd be curious to know what happened.

comment:17 Changed 12 years ago by blb@…

Resolution: invalid
Status: newclosed

It looks like the Headers stuff is done by Xcode, whereas the rest is base OS stuff. Maybe something happened with the 10.5.7 update and/or Xcode?

comment:18 Changed 12 years ago by nefar@…

If that's the case, then 'invalid' doesn't seem like the right resolution to the ticket. There was clearly an issue here.

comment:19 Changed 12 years ago by blb@…

There is some kind of issue, but from MacPorts' point of view, it is invalid since this appears to have been caused by (my theory anyway) either a system update like to 10.5.7, or Xcode, with one of those changes having some kind of issue. Since MacPorts doesn't mess with anything in /System/Library other than using files found there (or failing to compile when it can't find some as in this case), I don't see a MacPorts issue here.

You may want to try filing a radar with Apple but since we don't have much to go on other than aftereffects, I have no idea how they'll handle it.

comment:20 Changed 12 years ago by nefar@…

Someone mentioned that there's not a better resolution than 'invalid'? Maybe that should be fixed. My gripe is with the resolution status, because it's so very misleading. "WONT FIX", or something else would be more appropriate.

comment:21 Changed 12 years ago by blb@…

True, invalid isn't quite perfect but "won't fix" isn't quite technically correct either since there isn't any changes which could be made in MacPorts to deal with this. 'worksforme' would be closest, though we could ponder adding a 'system' or similar status...

Note: See TracTickets for help on using tickets.