View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014207CMakeCMakepublic2013-06-07 09:012013-11-04 09:33
ReporterGreg Eisenhauer 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
Platformtitan.ccs.ornl.govOSCray Linux EnvironmentOS Version
Product VersionCMake 2.8.11 
Target VersionFixed in Version 
Summary0014207: with PGI compilers, simple C++ program plus C library project fails to link
DescriptionAttached is a tar file with two simple source files and a CMake spec. This is a very simple example of a C++ hello world program including a C library. The CMakeList.txt looks like this:

add_library(dummy help.c)
ADD_EXECUTABLE(main main.cpp)
target_link_libraries(main dummy)

The C++ program doesn't actually reference the library, so you can try it with or without the target_link_libraries() line. If you try this with the PGI compilers, and include the dummy library you get a link error, "undefined reference to `__zceh_uncaught_exception'". This appears to be because Cmake has spuriously added -lstdc++ to the link line. (A manual link without -lstdc++ works without error.) If you comment out the target_link_libraries(), all is well, -lstdc++ doesn't appear and the link goes fine.
Steps To Reproduce# where CC and cc are PGI compilers on Titan
#
untar cmake_test.tar
cd cmake_test.tar
setenv CC cc
setenv CXX CC
cmake .
make
Additional Information-- The C compiler identification is PGI 12.10.0
-- The CXX compiler identification is PGI 12.10.0
I've tested this with cmake 2.8.6, 2.8.10.2, and with a fresh build from GIT. I've tested with all the versions of the PGI compilers available on titan. All combinations show the same problem of spuriously adding -lstdc++ to the link line.

I've tested this on sith.ccs.ornl.gov with various versions of cmake and PGI and *CANNOT* duplicate the problem. I don't currently have access to PGI compilers on any other machines, so this may be something specific to Titan. I've dumped all variables and attributes for the two targets, and stdc++ doesn't seem to appear in anything other than CMAKE_C_IMPLICIT_LINK_LIBRARIES.

Sorry I haven't been able to duplicate this on anything except titan.ccs.ornl.gov, which is a rather unique and restricted machine, but I know the folks at kitware collaborate there, so hopefully someone can check this out.
TagsNo tags attached.
Attached Filestar file icon cmake_test.tar [^] (5,120 bytes) 2013-06-07 09:01
gz file icon CMakeFiles.tar.gz [^] (4,878,478 bytes) 2013-06-07 10:15

 Relationships

  Notes
(0033249)
Brad King (manager)
2013-06-07 09:11

 Please tar up the CMakeFiles directory from the top of a (fresh) build tree after the first CMake run on it and attach it here.
(0033251)
Greg Eisenhauer (reporter)
2013-06-07 10:16

 Attached...
(0033252)
Brad King (manager)
2013-06-07 11:04

 I seen no stdc++ in the implicit link info:

$ grep IMPLICIT_LINK CMakeFiles/2.8.11.20130604-gd397/CMake*Compiler.cmake
CMakeFiles/2.8.11.20130604-gd397/CMakeCCompiler.cmake:set(CMAKE_C_IMPLICIT_LINK_LIBRARIES "rca;AtpSigHCommData;AtpSigHandler;scicpp_pgi;sci_pgi_mp;stdc++;mpich_pgi;mpl;rt;xpmem;dmapp;ugni;pmi;alpslli;alpsutil;udreg;pthread;pgmp;pthread;pgf90;pgf90_rpm1;pgf902;pgf90rtl;pgftnrtl;nspgc;pgc;rt;pthread;m;c;c")
CMakeFiles/2.8.11.20130604-gd397/CMakeCCompiler.cmake:set(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/opt/cray/udreg/2.3.2-1.0401.5929.3.3.gem/lib64;/opt/cray/ugni/4.0-1.0401.5928.9.5.gem/lib64;/opt/cray/pmi/4.0.1-1.0000.9421.73.3.gem/lib64;/opt/cray/dmapp/3.2.1-1.0401.5983.4.5.gem/lib64;/opt/cray/xpmem/0.1-2.0401.36790.4.3.gem/lib64;/opt/cray/rca/1.0.0-2.0401.38656.2.2.gem/lib64;/opt/cray/mpt/5.6.3/gni/mpich2-pgi/119/lib;/opt/cray/libsci/12.0.00/pgi/119/interlagos/lib;/opt/cray/xe-sysroot/4.1.40/usr/lib64;/opt/cray/xe-sysroot/4.1.40/lib64;/opt/cray/xe-sysroot/4.1.40/usr/lib/alps;/usr/lib/alps;/opt/pgi/13.3.0/linux86-64/13.3/lib;/usr/lib64;/usr/lib64/gcc/x86_64-suse-linux/4.3;/opt/cray/atp/1.6.1/lib")
CMakeFiles/2.8.11.20130604-gd397/CMakeCCompiler.cmake:set(CMAKE_C_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")
CMakeFiles/2.8.11.20130604-gd397/CMakeCXXCompiler.cmake:set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "rca;AtpSigHCommData;AtpSigHandler;scicpp_pgi;sci_pgi_mp;mpichcxx_pgi;mpich_pgi;mpichcxx_pgi;mpl;rt;xpmem;dmapp;ugni;pmi;alpslli;alpsutil;udreg;pthread;zceh;stdmpz;Cmpz;pgmp;pthread;pgf90;pgf90_rpm1;pgf902;pgf90rtl;pgftnrtl;nspgc;pgc;rt;pthread;m;c;c")
CMakeFiles/2.8.11.20130604-gd397/CMakeCXXCompiler.cmake:set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/opt/cray/udreg/2.3.2-1.0401.5929.3.3.gem/lib64;/opt/cray/ugni/4.0-1.0401.5928.9.5.gem/lib64;/opt/cray/pmi/4.0.1-1.0000.9421.73.3.gem/lib64;/opt/cray/dmapp/3.2.1-1.0401.5983.4.5.gem/lib64;/opt/cray/xpmem/0.1-2.0401.36790.4.3.gem/lib64;/opt/cray/rca/1.0.0-2.0401.38656.2.2.gem/lib64;/opt/cray/mpt/5.6.3/gni/mpich2-pgi/119/lib;/opt/cray/libsci/12.0.00/pgi/119/interlagos/lib;/opt/cray/xe-sysroot/4.1.40/usr/lib64;/opt/cray/xe-sysroot/4.1.40/lib64;/opt/cray/xe-sysroot/4.1.40/usr/lib/alps;/usr/lib/alps;/opt/pgi/13.3.0/linux86-64/13.3/lib;/usr/lib64;/usr/lib64/gcc/x86_64-suse-linux/4.3;/opt/cray/atp/1.6.1/lib")
CMakeFiles/2.8.11.20130604-gd397/CMakeCXXCompiler.cmake:set(CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "")

Does the build actually fail in the test tree you just used?
(0033253)
Greg Eisenhauer (reporter)
2013-06-07 11:09

 stdc++ is actually in the text you attached. It's the 6th library in the CMAKE_C_IMPLICIT_LINK_LIBRARIES. If you grep for stdc++ instead you'll find:

cmake_test/build> cd CMakeFiles/
Directory: /ccs/home/eisen/cmake_test/build/CMakeFiles
build/CMakeFiles> grep stdc++ */*
2.8.11.20130604-gd397/CMakeCCompiler.cmake:set(CMAKE_C_IMPLICIT_LINK_LIBRARIES "rca;AtpSigHCommData;AtpSigHandler;scicpp_pgi;sci_pgi_\
mp;stdc++;mpich_pgi;mpl;rt;xpmem;dmapp;ugni;pmi;alpslli;alpsutil;udreg;pthread;pgmp;pthread;pgf90;pgf90_rpm1;pgf902;pgf90rtl;pgftnrtl\
;nspgc;pgc;rt;pthread;m;c;c")
main.dir/link.txt:/opt/cray/xt-asyncpe/5.17/bin/CC CMakeFiles/main.dir/main.cpp.o -o main libdummy.a -lstdc++
build/CMakeFiles> cd ..
Directory: /ccs/home/eisen/cmake_test/build
cmake_test/build> make
[ 50%] Built target dummy
Linking CXX executable main
/opt/pgi/13.3.0/linux86-64/13.3/lib/libCmpz.a(eh_util.o): In function `std::uncaught_exception(void)':
eh_util.c:(.text+0x227): undefined reference to `__zceh_uncaught_exception'
/usr/bin/ld: link errors found, deleting executable `main'
make[2]: *** [main] Error 2
make[1]: *** [CMakeFiles/main.dir/all] Error 2
make: *** [all] Error 2
cmake_test/build>
(0033254)
Brad King (manager)
2013-06-07 11:51

 Re 0014207:0033253: Oops, I looked only through the C++ implicit libs.
(0033255)
Greg Eisenhauer (reporter)
2013-06-07 11:55

 Yeah, I'm guessing that it is in the C implicit libs and not the C++ ones is perhaps the problem here.
(0033256)
Brad King (manager)
2013-06-07 12:01

 In CMakeFiles/CMakeOutput.log I see CMake's report of running the C compiler with the -v option to get its implicit link line:

 /opt/cray/xt-asyncpe/5.17/bin/cc -v .../CMakeCCompilerABI.c.o -o cmTryCompileExec1384233744
 /opt/cray/xt-asyncpe/5.17/bin/cc: INFO: Compiling for compute nodes running CLE.
 /sw/xk6/altd/bin/ld ... -lstdc++ ...

Note the call to ld explicitly passes stdc++. This means that your C compiler is linking to stdc++ whenever it is asked to run the linker.

CMake is parsing this information and adding stdc++ to the list of implicit C libraries. CMake's mixed-language linking support (meant for C++ and Fortran) is detecting that you're linking with the C++ compiler but that the C compiler wants some libraries (stdc++) that the C++ compiler does not add. That's why it adds the library.

This appears to be a problem with the way the local C compiler is configured.
(0033258)
Greg Eisenhauer (reporter)
2013-06-07 18:16

 Thanks for the analysis Brad, I agree. Unfortunately the Titan compilation environment is somewhat messy and custom. They're not invoking compilers directly, but through a bunch of scripts that add their own default options. I think I've tracked down the script that is responsible for the spurious -lstdc++ and one of my ORNL colleagues is taking it up with NCCS. I think we can mark this as not CMake's bug. Sorry for taking up your time, but appreciate the diagnostic help.
(0033265)
Brad King (manager)
2013-06-10 10:29

 Thanks for reporting back. Resolving as "no change required".
(0034369)
Robert Maynard (manager)
2013-11-04 09:33

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2013-06-07 09:01 Greg Eisenhauer New Issue
2013-06-07 09:01 Greg Eisenhauer File Added: cmake_test.tar
2013-06-07 09:11 Brad King Note Added: 0033249
2013-06-07 10:15 Greg Eisenhauer File Added: CMakeFiles.tar.gz
2013-06-07 10:16 Greg Eisenhauer Note Added: 0033251
2013-06-07 11:04 Brad King Note Added: 0033252
2013-06-07 11:09 Greg Eisenhauer Note Added: 0033253
2013-06-07 11:51 Brad King Note Added: 0033254
2013-06-07 11:55 Greg Eisenhauer Note Added: 0033255
2013-06-07 12:01 Brad King Note Added: 0033256
2013-06-07 18:16 Greg Eisenhauer Note Added: 0033258
2013-06-10 10:29 Brad King Note Added: 0033265
2013-06-10 10:29 Brad King Status new => resolved
2013-06-10 10:29 Brad King Resolution open => no change required
2013-11-04 09:33 Robert Maynard Note Added: 0034369
2013-11-04 09:33 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team