MantisBT - CMake
View Issue Details
0016100CMakeCMakepublic2016-05-11 03:222016-06-10 14:21
Michał Górny 
Brad King 
normalmajoralways
closedfixed 
CMake 3.5.2 
CMake 3.6CMake 3.6 
0016100: Implicit link information parsing reads the wrong line from 'pathcc -v' output
$ pathcc --version
PathScale EKOPath(tm) Compiler Suite: Version 6.0.779
Built on:
Thread model: posix
GNU gcc compatible version 4.2.1
[...]

When CMake attempts to get ABI info from the compiler, it gets the following output:

[2/2] Linking C executable cmTC_cfda2
PathScale EKOPath(tm) Compiler Suite: Version 6.0.570
Built on:
Thread model: posix
GNU gcc compatible version 4.2.1
/opt/ekopath/lib/6.0.570/x8664/ldfe -v -TARG:isa=x86_64 -TARG:processor=barcelona -TARG:sse=on -TARG:sse2=on -TARG:sse3=on -TARG:ssse3=off -TARG:sse4a=off -TARG:sse4_1=off -TARG:sse4_2=off -TARG:avx=off -TARG:avx2=off -TARG:avx512dq=off -TARG:avx512vl=off -TARG:avx512bw=off -TARG:avx512er=off -TARG:avx512f=off -TARG:fma=off -TARG:fma4=off -TARG:xop=off -TARG:aes=off -TARG:pclmul=off -TARG:3dnow=off -o cmTC_cfda2 -show CMakeFiles/cmTC_cfda2.dir/CMakeCCompilerABI.c.o --as-needed -lgcc -lc -lmv -lmpath -lm --no-as-needed -lpscrt -lc
/opt/ekopath/lib/6.0.570/x8664/../../../x8664/bin/ld -L/opt/ekopath/lib/6.0.570/x8664/64/system-provided/ -L/opt/ekopath/lib/6.0.570/x8664/64/ -rpath=/opt/ekopath/lib/6.0.570/x8664/64/ --dynamic-linker=/lib64/ld-linux-x86-64.so.2 -melf_x86_64 --eh-frame-hdr -v -o cmTC_cfda2 /opt/ekopath/lib/6.0.570/x8664/64/system-provided/crt1.o /opt/ekopath/lib/6.0.570/x8664/64/system-provided/crti.o /opt/ekopath/lib/6.0.570/x8664/64/crtbegin.o CMakeFiles/cmTC_cfda2.dir/CMakeCCompilerABI.c.o --as-needed -L/opt/ekopath/lib/6.0.570/x8664/64/ -lgcc /lib64/libc.so.6 /usr/lib64/libc_nonshared.a /lib64/ld-linux-x86-64.so.2 -L/opt/ekopath/lib/6.0.570/x8664/64/ -lmv -L/opt/ekopath/lib/6.0.570/x8664/64/ -lmpath /lib64/libm.so.6 /lib64/libmvec.so.1 --no-as-needed /opt/ekopath/lib/6.0.570/x8664/64//libpscrt.a /lib64/libc.so.6 /usr/lib64/libc_nonshared.a /lib64/ld-linux-x86-64.so.2 /opt/ekopath/lib/6.0.570/x8664/64/crtend.o /opt/ekopath/lib/6.0.570/x8664/64/system-provided/crtn.o
GNU ld (GNU Binutils) 2.25


Parsed C implicit link information from above output:
  link line regex: [^( *|.*[/\])(ld|([^/\]+-)?ld|collect2)[^/\]*( |$)]
[...]
  link line: [/opt/ekopath/lib/6.0.570/x8664/ldfe -v -TARG:isa=x86_64 -TARG:processor=barcelona -TARG:sse=on -TARG:sse2=on -TARG:sse3=on -TARG:ssse3=off -TARG:sse4a=off -TARG:sse4_1=off -TARG:sse4_2=off -TARG:avx=off -TARG:avx2=off -TARG:avx512dq=off -TARG:avx512vl=off -TARG:avx512bw=off -TARG:avx512er=off -TARG:avx512f=off -TARG:fma=off -TARG:fma4=off -TARG:xop=off -TARG:aes=off -TARG:pclmul=off -TARG:3dnow=off -o cmTC_cfda2 -show CMakeFiles/cmTC_cfda2.dir/CMakeCCompilerABI.c.o --as-needed -lgcc -lc -lmv -lmpath -lm --no-as-needed -lpscrt -lc ]
[...]


However, this is not the correct line. ldfe is an internal helper, and it is immediately followed by a call to 'ld' which has all the correct -L flags. As a result, pathcc doesn't parse the correct data and doesn't determine multiarch tuple on Debian.

Maybe it would be appropriate to not stop at the first line matching the regular expression, and parse the last line matching it instead? This would prevent CMake from parsing the wrapper when it's followed by an actual ld call.
1. install ekopath nightly (e.g. http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-2016-04-28-installer.run [^]),

2. attempt to build any CMake project.

On multiarch systems, find_library() won't be able to find any libraries. On other systems, you can also see the problem when looking at CMakeOutput.log.
No tags attached.
patch 0001-Exclude-ldfe-when-parsing-implicit-link-info-for-pat.patch (1,184) 2016-05-11 13:55
https://public.kitware.com/Bug/file/5690/0001-Exclude-ldfe-when-parsing-implicit-link-info-for-pat.patch
Issue History
2016-05-11 03:22Michał GórnyNew Issue
2016-05-11 08:49Brad KingNote Added: 0041048
2016-05-11 13:47Michał GórnyNote Added: 0041052
2016-05-11 13:55Michał GórnyFile Added: 0001-Exclude-ldfe-when-parsing-implicit-link-info-for-pat.patch
2016-05-11 14:37Brad KingNote Added: 0041053
2016-05-11 15:09Brad KingNote Added: 0041055
2016-05-11 15:09Brad KingAssigned To => Brad King
2016-05-11 15:09Brad KingStatusnew => resolved
2016-05-11 15:09Brad KingResolutionopen => fixed
2016-05-11 15:09Brad KingFixed in Version => CMake 3.6
2016-05-11 15:09Brad KingTarget Version => CMake 3.6
2016-05-11 15:46Michał GórnyNote Added: 0041056
2016-06-10 14:21Kitware RobotNote Added: 0041175
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0041048)
Brad King   
2016-05-11 08:49   
Interesting. There is a huge variety of behaviors with compiler front-end "-v" output and the "ld" command can take several different forms and names. I don't know whether switching to the last matching line is correct in all cases either. The expression we're using to tolerate all that is accepting "ldfe". The surrounding logic already has several special cases for specific tools IIRC so perhaps the "ld" expression could be updated to something like "ld([^f]|f[^e])" in order to filter out this specific case.
(0041052)
Michał Górny   
2016-05-11 13:47   
Åke Sandgren from PathScale has suggested using linker_exclude_regex to solve this easily. I'll attach a patch in a minute.
(0041053)
Brad King   
2016-05-11 14:37   
Thanks for working on a patch.

> - set(linker_exclude_regex "collect2 version |^[A-Za-z0-9_]+=")
> + set(linker_exclude_regex "collect2 version |^[A-Za-z0-9_]+=|ldfe ")

I'd like to try to be a bit more specific. Perhaps:

  set(linker_exclude_regex "collect2 version |^[A-Za-z0-9_]+=|/ldfe ")

?
(0041055)
Brad King   
2016-05-11 15:09   
I've applied the patch with the modification mentioned in 0016100:0041053:

 CMakeParseImplicitLinkInfo: Exclude pathcc ldfe lines
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25845b10 [^]

Thanks!
(0041056)
Michał Górny   
2016-05-11 15:46   
It seems to work for me, thanks a lot.
(0041175)
Kitware Robot   
2016-06-10 14:21   
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.