[cmake-developers] [CMake 0016100]: Implicit link information parsing reads the wrong line from 'pathcc -v' output

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
https://public.kitware.com/Bug/view.php?id=16100 
====================================================================== 
Reported By:                Michał Górny
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   16100
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2016-05-11 03:22 EDT
Last Modified:              2016-05-11 03:22 EDT
====================================================================== 
Summary:                    Implicit link information parsing reads the wrong
line from 'pathcc -v' output
Description: 
$ 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.

Steps to Reproduce: 
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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2016-05-11 03:22 Michał Górny   New Issue                                    
======================================================================