Opened 15 years ago
Closed 10 years ago
#23857 closed defect (worksforme)
cmake 2.8.0 fails with non-default XCode 3.2.1 location
Reported by: | pgf | Owned by: | cssdev |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | ports | Version: | 1.8.2 |
Keywords: | Cc: | cooljeanius (Eric Gallager), mojca (Mojca Miklavec) | |
Port: | cmake |
Description
cmake 2.8.0 fails to build on Max OS X 10.6.2
Platform informations:
Model: iMac10.1
System version: Mac OS X 10.6.2 (10C540)
Kernel version: Darwin 10.2.0
64 bit kernel and extensions: yes
Xcode version: 3.2.1
port version: 1.8.2
CMake has bootstrapped. Now run make. ---> Building cmake DEBUG: Executing org.macports.build (cmake) DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cmake/work/cmake-2.8.0" && /usr/bin/make -j2 all' CMake Error: Parse error in cache file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cmake/work/cmake-2.8.0/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.6.sdk -- Configuring incomplete, errors occurred! make: *** [cmake_check_build_system] Error 1 Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cmake/work/cmake-2.8.0" && /usr/bin/make -j2 all " returned error 2 DEBUG: Backtrace: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cmake/work/cmake-2.8.0" && /usr/bin/make -j2 all " returned error 2 while executing "command_exec build" (procedure "portbuild::build_main" line 9) invoked from within "$procedure $targetname" Warning: the following items did not execute (for cmake): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. To report a bug, see <http://guide.macports.org/#project.tickets>
CMakeCache.txt attached.
Attachments (1)
Change History (14)
Changed 15 years ago by pgf
Attachment: | CMakeCache.txt added |
---|
comment:1 Changed 15 years ago by jmroot (Joshua Root)
Keywords: | cmake removed |
---|---|
Owner: | changed from macports-tickets@… to css@… |
comment:2 Changed 15 years ago by cssdev
Status: | new → assigned |
---|
Do you have XCode installed into a different location? Your CMAKE_OSX_SYSROOT
looks different from mine:
CMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.6.sdk
This post indicates someone encountering a similar problem with XCode 3.2.1 not installed into the default location. I think the catch will be trying to tell the CMake port to look for the XCode development tools in a non-standard location. Do you have all the SDKs installed into /Developer/XCode3.2.1?
comment:3 Changed 15 years ago by pgf
First of all thanks for your reply!
Yes, XCode is installed in a different directory, /Developer/Xcode3.2.1 . Setting CMAKE_OSX_SYSROOT to the exact location:
CMAKE_OSX_SYSROOT:PATH=/Developer/Xcode3.2.1/SDKs/MacOSX10.6.sdk
solved the problem!
Thank you very much again!
comment:4 follow-ups: 6 8 Changed 15 years ago by cssdev
So the catch is twofold ...
- Can MacPorts easily detect that XCode 3.2.1 is installed into a different location?
- How can the CMake Portfile indicate this location when configuring the port?
comment:5 Changed 15 years ago by cssdev
Priority: | Normal → Low |
---|---|
Summary: | cmake 2.8.0 build failed → cmake 2.8.0 fails with non-default XCode 3.2.1 location |
comment:6 Changed 15 years ago by jmroot (Joshua Root)
Replying to css@…:
- Can MacPorts easily detect that XCode 3.2.1 is installed into a different location?
That's the developer_dir variable.
comment:8 Changed 14 years ago by cssdev
Replying to css@…:
- How can the CMake Portfile indicate this location when configuring the port?
During the configure phase, provide an init file to the cmake bootstrap that specifies CMAKE_OSX_SYSROOT
as the developer_dir
.
comment:9 Changed 13 years ago by chbrosso@…
The bug is fixed upstream (see patch in issue page) and will be rolled in 2.8.5:
comment:10 Changed 13 years ago by cssdev
Any confirmation that this may now be closed with cmake 2.8.5?
comment:13 Changed 10 years ago by mojca (Mojca Miklavec)
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Given that we have CMake 3.0.0 now and that the bug was supposed to be fixed already way back in 2.8.5, I suspect the problem has been fixed, so I'm closing the ticket. If that's not the case and it's still a problem, please reopen the ticket.
Please remember to cc the maintainer.