| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0007359 | CMake | CMake | public | 2008-07-17 15:36 | 2008-10-13 19:19 | ||||
| Reporter | Sean McBride | ||||||||
| Assigned To | Alex Neundorf | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | Mac OS X | OS | Mac OS X | OS Version | 10.5 | ||||
| Product Version | CMake-2-6 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0007359: CMake CVS does not compile with Apple llvm-gcc-4.2 (from Xcode 3.1) | ||||||||
| Description | The recently released Xcode 3.1 now comes with several new compilers, including llvm-gcc-4.2. CMake CVS builds with gcc 4.0 and 4.2 but not with llvm: Linking CXX static library libcmsys.a Error running link command: No such file or directory make[2]: *** [Source/kwsys/libcmsys.a] Error 2 make[1]: *** [Source/kwsys/CMakeFiles/cmsys.dir/all] Error 2 make: *** [all] Error 2 You select llvm-gcc like so: export CC=/Developer/usr/bin/llvm-gcc-4.2 export CXX=/Developer/usr/bin/llvm-g++-4.2 For llvm info: http://developer.apple.com/releasenotes/DeveloperTools/RN-llvm-gcc/index.html [^] Unlike gcc 4.0 and 4.2, llvm is not 'ready for primetime', so this may be an llvm bug. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |  llvm.patch [^] (3,030 bytes) 2008-09-06 13:50 [Show Content]
| ||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0012972) Sean McBride (reporter) 2008-08-08 14:22 |
Correction, CMake does in fact compile using llvm-gcc. The problem is elsewhere. Consider: $ which gcc /usr/bin/gcc $ which llvm-gcc /Developer/usr/bin/llvm-gcc $ which ar /usr/bin/ar Note that gcc and ar are in the same folder, and that llvm-gcc is not. So when I do: export CC=/Developer/usr/bin/llvm-gcc-4.2 export CXX=/Developer/usr/bin/llvm-g++-4.2 CMake does not find ar in the same folder. Verbose result: Linking CXX static library libcmsys.a cd /Volumes/Extra/kitware/CMake-bin-llvm/Source/kwsys && "/Applications/CMake 2.6-1.app/Contents/bin/cmake" -P CMakeFiles/cmsys.dir/cmake_clean_target.cmake cd /Volumes/Extra/kitware/CMake-bin-llvm/Source/kwsys && "/Applications/CMake 2.6-1.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/cmsys.dir/link.txt --verbose=1 CMAKE_AR-NOTFOUND cr libcmsys.a CMakeFiles/cmsys.dir/ProcessUNIX.o CMakeFiles/cmsys.dir/Base64.o CMakeFiles/cmsys.dir/MD5.o CMakeFiles/cmsys.dir/Terminal.o CMakeFiles/cmsys.dir/System.o CMakeFiles/cmsys.dir/String.o CMakeFiles/cmsys.dir/Directory.o CMakeFiles/cmsys.dir/DynamicLoader.o CMakeFiles/cmsys.dir/Glob.o CMakeFiles/cmsys.dir/RegularExpression.o CMakeFiles/cmsys.dir/SystemTools.o CMakeFiles/cmsys.dir/CommandLineArguments.o CMakeFiles/cmsys.dir/Registry.o CMakeFiles/cmsys.dir/IOStream.o CMakeFiles/cmsys.dir/SystemInformation.o Error running link command: No such file or directory make[2]: *** [Source/kwsys/libcmsys.a] Error 2 make[1]: *** [Source/kwsys/CMakeFiles/cmsys.dir/all] Error 2 make: *** [all] Error 2 Note the all-important "CMAKE_AR-NOTFOUND" So perhaps we can improve CMake's autodetection of 'ar'? If it's not in the same folder as the compiler, could it then check /usr/bin/? |
|
(0013064) Bill Hoffman (manager) 2008-08-19 13:52 |
This sort of goes under the section of "if the compiler is not installed correctly, cmake can't work". CMake should give some better error when AR is not found. However, it will assume that this stuff is in the PATH, and that you can compile correctly from the command line. |
|
(0013066) Sean McBride (reporter) 2008-08-19 14:09 |
Bill, I understand what you mean, but in this case the compiler is installed correctly. My Xcode 3.1 install is a default install, llvm-gcc's default location is /Developer/usr/bin/llvm-gcc-4.2. As I look more closely, I'm not sure why cmake is not finding 'ar'. There are in fact 2: $ which -a ar /usr/bin/ar /Developer/usr/bin/ar $ which -a gcc /usr/bin/gcc /Developer/usr/bin/gcc $ which -a llvm-gcc /Developer/usr/bin/llvm-gcc It seems what's special about llvm-gcc is that there is only one. Additionally, /Developer/usr/bin is in my PATH, but after /usr/bin. $ echo $PATH /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin:/usr/local/bic/bin:/usr/local/mni/bin:/Developer/usr/bin:/Library/Tcl/bin Does this new info help? I argue that CMake should be able to find a default install of llvm-gcc. A better error message for 'ar' not being found would be nice of course, but is a separate issue I suppose. |
|
(0013074) Bill Hoffman (manager) 2008-08-19 14:58 |
If ar is in the path, it should find it.... It does this: FIND_PROGRAM(CMAKE_AR NAMES ${_CMAKE_TOOLCHAIN_PREFIX}ar HINTS ${_CMAKE_TOOLCHAIN_LOCATION}) You are not setting any toolchain stuff are you? If you just have a project that has FIND_PROGRAM(CMAKE_AR_TMP NAMES ar) does it work? |
|
(0013326) Soren Harward (reporter) 2008-09-06 07:02 |
On my Gentoo Linux box, whenever I set the CC and CXX variables manually, cmake-2.6 fails to detect not just "ar", but any of the other executables in the toolchain: ld, objdump, nm, etc. I end up having to manually specify locations for each of the tools if the build process needs them. |
|
(0013329) Bill Hoffman (manager) 2008-09-06 09:43 |
Does 2.4 work for you on gentoo? It must be something specific to your box, as there are lots of folks with gentoo and CMake, and this type of thing would be unacceptable. CMake does not detect ld, objdump, or nm anyway... It does look for ar, and if it is in the path it should find it. |
|
(0013330) Soren Harward (reporter) 2008-09-06 13:14 |
2.4.6 works okay. The reason you don't have masses of Gentoo users complaining about CMake being broken is that Portage doesn't try to override the compiler. This is too bad, because for autotools-based projects, Portage will use distcc and ccache for the build. I'm doing Amarok2 (for KDE4) work, so I would like to override the default /usr/bin/g++ location so that I can use distcc and ccache. |
|
(0013331) Alex Neundorf (developer) 2008-09-06 13:56 |
Does the attached patch llvm.patch fix it for you ? "llvm-" was interpreted as the prefix for a cross compiling toolchain, and these toolchains then use the same prefix for the binutils tools. The patch changes the detection so thatthe prefix must now have at least two dashes (which all gcc cross compilers I know have). There is also some spec for this but I can't find it right now. Alex |
|
(0013332) Bill Hoffman (manager) 2008-09-06 14:08 |
OK I think we have two separate issues in the bug report now... The gentoo issue and the llvm- issue. stharward can you give a more complete explanation of the problem and how to reproduce it? Some logs of what your are doing and stuff like that. Also comparative logs with 2.4.6. Thanks. |
|
(0013334) Alex Neundorf (developer) 2008-09-06 19:17 |
The following works for me both with 2.4.6 as well as cvs HEAD: $ export CC="/opt/ccache/bin/ccache gcc" $ cd build $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /opt/ccache/bin/ccache -- Check for working C compiler: /opt/ccache/bin/ccache -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/alex/src/tests/hello1/bhead-ccache $ make What goes wrong for you ? |
|
(0013336) Alex Neundorf (developer) 2008-09-07 16:54 |
The attached patch was not very good. E.g. ELDK for arm has the compiler arm-linux-gcc, but also "arm-gcc", which clearly has only one dash. Instead now explicitely check for "llvm-" and strip that if found from the prefix. This should make llvm work. Committed to cvs. Alex |
|
(0013340) Bill Hoffman (manager) 2008-09-07 23:03 |
So, are you saying that cmake can no longer support a compiler with a "-" in the name of the executable? I think that goes a bit too far with support for cross compiling... Perhaps it should fall back on the regular path for ar, ld and other things if it does not find them with the "-" name. Seems a bit arbitrary, and is going to give headaches as we move forward. |
|
(0013353) Sean McBride (reporter) 2008-09-08 11:00 |
With the current cvs code, my original problem is fixed. Thank you. If this fix can get into 2.6.2, I can create a new dashboard that builds CMake with llvm-gcc-4.2. |
|
(0013356) Brad King (manager) 2008-09-08 14:08 |
I don't think special casing one example of herusitic failure is a long-term solution. Instead, some of the following ideas should be used: 1.) Only do this when CMAKE_CROSSCOMPILING is true. 2.) Move the extraction of the toolchain prefix until after the compiler id and only do it when the compiler id is GNU. 3.) In CMakeFindBinUtils, treat the prefix as a hint. Use it to look for 'ar'. If found, use the prefix for all the tools. Otherwise, drop the prefix. All this behavior should be cached somehow (perhaps in the compiler info files). 4.) Provide a way for a user toolchain file to set the prefix. |
|
(0013361) Alex Neundorf (developer) 2008-09-08 16:46 |
Bill: yes, before the patch everything before a dash was considered a prefix for a cross compiling toolchain, but only if it matches .+-g?cc, i.e. it must end with "-cc" or "-gcc". Bedore llvm I didn't see any other compiler executable which looked like this. Brad: 1 & 2): yes, that's what I want to do. 3) I wouldn't do this. If I do 1 & 2), I have not seen any toolchain (i.e. GNU toolchain), where there is foo-gcc, but no foo- binutils. 4) It can be set right now already, but it's undocumented and internal (i.e. prefixed with an underscore), the variable is _CMAKE_TOOLCHAIN_PREFIX Alex |
|
(0013362) Alex Neundorf (developer) 2008-09-08 16:51 |
Related note: I guess llvm-gcc is right detected as GNU ? If we want to detect it as LLVM, we could add a check for __llvm__ to CMakeC[XX]CompilerId.c.in. But actually I'm not sure this would be correct. Am I right that llvm-gcc is a gcc version which uses the gcc frontend, but the produces code for llvm ? Then it is actually indeed somewhat more similar to a gcc cross compiler and should be handled as gcc. Alex |
|
(0013363) Sean McBride (reporter) 2008-09-08 16:58 |
I don't enough about CMake's internals to really follow your discussion, but: 1) The llvm-gcc I'm talking about is a default part of Xcode 3.1. More info here: http://developer.apple.com/releasenotes/DeveloperTools/RN-llvm-gcc/index.html [^] 2) I am not cross compiling. I'm just trying to use my OS vendor's newest compiler. I'm trying to do so like so: export CC=/Developer/usr/bin/llvm-gcc-4.2 export CXX=/Developer/usr/bin/llvm-g++-4.2 which I believe is supposed to be how I choose the compiler. |
|
(0013364) Bill Hoffman (manager) 2008-09-08 17:07 |
Also, what if someone does something like this: ln -s gcc gcc-for-me Then tries to use gcc-for-me? Seems like doing something special just because of the name of the compiler is going to cause some trouble. |
|
(0013366) Alex Neundorf (developer) 2008-09-08 17:19 |
If he forces cmake to use that symlink and if he is cross compiling, it will break. But I really think this is something we can live with. Not many people do this, and if I do this check only when GCC && crosscompiling, we should really be on the safe side. Alex |
|
(0013869) Alex Neundorf (developer) 2008-10-13 19:19 |
Fixed in 2.6.2. Alex |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2008-07-17 15:36 | Sean McBride | New Issue | |
| 2008-08-08 14:22 | Sean McBride | Note Added: 0012972 | |
| 2008-08-19 13:52 | Bill Hoffman | Note Added: 0013064 | |
| 2008-08-19 13:52 | Bill Hoffman | Status | new => assigned |
| 2008-08-19 13:52 | Bill Hoffman | Assigned To | => Bill Hoffman |
| 2008-08-19 14:09 | Sean McBride | Note Added: 0013066 | |
| 2008-08-19 14:58 | Bill Hoffman | Note Added: 0013074 | |
| 2008-09-06 07:02 | Soren Harward | Note Added: 0013326 | |
| 2008-09-06 09:43 | Bill Hoffman | Note Added: 0013329 | |
| 2008-09-06 13:14 | Soren Harward | Note Added: 0013330 | |
| 2008-09-06 13:50 | Alex Neundorf | File Added: llvm.patch | |
| 2008-09-06 13:56 | Alex Neundorf | Note Added: 0013331 | |
| 2008-09-06 14:06 | Bill Hoffman | Assigned To | Bill Hoffman => Alex Neundorf |
| 2008-09-06 14:08 | Bill Hoffman | Note Added: 0013332 | |
| 2008-09-06 19:17 | Alex Neundorf | Note Added: 0013334 | |
| 2008-09-07 16:54 | Alex Neundorf | Note Added: 0013336 | |
| 2008-09-07 23:03 | Bill Hoffman | Note Added: 0013340 | |
| 2008-09-08 11:00 | Sean McBride | Note Added: 0013353 | |
| 2008-09-08 14:08 | Brad King | Note Added: 0013356 | |
| 2008-09-08 16:46 | Alex Neundorf | Note Added: 0013361 | |
| 2008-09-08 16:51 | Alex Neundorf | Note Added: 0013362 | |
| 2008-09-08 16:58 | Sean McBride | Note Added: 0013363 | |
| 2008-09-08 17:07 | Bill Hoffman | Note Added: 0013364 | |
| 2008-09-08 17:19 | Alex Neundorf | Note Added: 0013366 | |
| 2008-10-13 19:19 | Alex Neundorf | Note Added: 0013869 | |
| 2008-10-13 19:19 | Alex Neundorf | Status | assigned => closed |
| 2008-10-13 19:19 | Alex Neundorf | Resolution | open => fixed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |