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                                    
======================================================================

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to