Linking LLVM causes gcov to fail - c++

Passing --coverage to gcc while also linking LLVM causes an undefined reference to `__gcov_exit' error from the linker. I've set up a fresh project to try to isolate this problem. You can view the source on github and inspect the compiler output on Travis-CI.
This is the difference between a coverage and a non-coverage build
-DCMAKE_CXX_FLAGS="--coverage"
This is the difference between an LLVM and a non-LLVM build
target_link_libraries(Test
PUBLIC
LLVMCore
)
The LLVM job succeeds. The Coverage job succeeds. The LLVM + Coverage job fails with this error
undefined reference to `__gcov_exit'

Notes:
Check [CMake 3.13]: CMAKE_<LANG>_FLAGS for details regarding which env var affects which cmake var - as you figured out in your (deleted) answer
Only noticed cxx_std_17 from CMake 3.8, so you might want to update your cmake_minimum_required
Forked your repo to [GitHub]: CristiFati/gcov_error - An attempt to reproduce the gcov/llvm linker error and did some debugging on it
Beware, I might delete it someday
Was able to get my head around Travis CI, it's a real gold-mine
At the beginning I thought that it would be a trivial fix (something related to -fprofile-arcs, -ftest-coverage, -lgcov flags) as noted in [Man7]: GCC(1) (--coverage option), but it wasn't.
I wasn't able to reproduce the problem on my Ubuntu 16 pc064 VM (although Travis is very nice, it's kind of slow for debugging purposes (especially when due to rushing one might forget or add an extra character when editing :) ) and also it doesn't offer the same access level that a local machine does,) because the environment:
CMake 3.5.1
GCC 5.4.0
LLVM 3.8.0
is pretty far away from what's on the Travis Docker image. I must mention that neither I tried building the packages from sources (that would probably have caused lots of headaches), nor did I try downloading them from the repositories where they are downloaded during CI builds (didn't even check if those repos are public). Anyway the VM was pretty much unusable because:
I couldn't reproduce the issue (after some minor changes to adapt to older tools), everything worked
More: I ran into [SO]: Error when using CMake with LLVM (#CristiFati's answer)
It was eating me alive, so I ended up building 48 freaking times (on Travis) in order to get it working, and that is only because I failed to notice the obvious.
The problem
For each of the 3 configurations I'm going to paste the compile and link (G++) commands generated (from your build: [Travis CI]: Kerndog73/gcov_error - Build #24)
LLVM:
/usr/bin/g++-7 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/lib/llvm-7/include -std=gnu++1z -o CMakeFiles/Test.dir/main.cpp.o -c /home/travis/build/Kerndog73/gcov_error/main.cpp
/usr/bin/g++-7 -rdynamic CMakeFiles/Test.dir/main.cpp.o -o Test -L/usr/lib/gcc/x86_64-linux-gnu/4.8 /usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread -lm /usr/lib/llvm-7/lib/libLLVMDemangle.a
Coverage:
/usr/bin/g++-7 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/lib/llvm-7/include --coverage -std=gnu++1z -o CMakeFiles/Test.dir/main.cpp.o -c /home/travis/build/Kerndog73/gcov_error/main.cpp
/usr/bin/g++-7 --coverage -rdynamic CMakeFiles/Test.dir/main.cpp.o -o Test
LLVM + Coverage:
/usr/bin/g++-7 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/lib/llvm-7/include --coverage -std=gnu++1z -o CMakeFiles/Test.dir/main.cpp.o -c /home/travis/build/Kerndog73/gcov_error/main.cpp
/usr/bin/g++-7 --coverage -rdynamic CMakeFiles/Test.dir/main.cpp.o -o Test -L/usr/lib/gcc/x86_64-linux-gnu/4.8 /usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread -lm /usr/lib/llvm-7/lib/libLLVMDemangle.a
After lots of ghosts chasing, I noticed -L/usr/lib/gcc/x86_64-linux-gnu/4.8 being passed to the linker when LLVM is included. GCC 4.8 is installed on the Docker, so apparently GCC 7.4 was used for compilation, and GCC 4.8 for linking, which is Undefined Behavior.
I'm also pasting the Collect command (closer to the linker) from a slight variation (with -v) of #3. (all the libraries specified with -l* and without the full path (e.g. -lgcov, -lgcc_s, -lgcc) have the wrong version because will be picked up from the wrong directory):
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccyDh97q.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o Test /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. CMakeFiles/Test.dir/main.cpp.o /usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread /usr/lib/llvm-7/lib/libLLVMDemangle.a -lstdc++ -lm -lgcov -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7/crtend.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.0
Some test commands placed in .travis.yml's after_script section, yielded the following output:
$ _GCOV_LIB7=/usr/lib/gcc/x86_64-linux-gnu/7/libgcov.a
$ (nm -S ${_GCOV_LIB7} 2>/dev/null | grep __gcov_exit) || echo ${_GCOV_LIB7}
0000000000001e40 000000000000008b T __gcov_exit
$ _GCOV_LIB48=/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcov.a
$ (nm -S ${_GCOV_LIB48} 2>/dev/null | grep __gcov_exit) || echo ${_GCOV_LIB48}
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcov.a
So, LibGCC (libgcov.a) was modified somewhere between the 2 involved versions (__gcov_exit symbol was added), and G++ knew it has one but Ld didn't provide it (because of the wrong lib) hence the error.
Now, why does LLVM add this library search path, I don't know (probably because it was built with GCC 4.8 - or smth close to it), but here's what I can think of:
LLVM is not meant to be used with GCC 7 (although I didn't find any such restriction while quickly browsing [LLVM]: Getting Started with the LLVM System)
A bug in LLVM (considering the other issue that I ran into, I tend to think this is the winner)
I found ways for both of them:
Use an older G++ (v4.8 - installed by default on the Docker)
export CXX=g++ (might even not be necessary)
G++ (not CMake this time) doesn't know about cxx_std_17, so the easiest way is to remove the afferent target_compile_features (the drawback is that code won't be C++17 "compliant")
Since I don't know how to "undo" passing the (faulty) library search path, the workaround that I came up with is to specify the correct one before it.
CMakeLists.txt:
cmake_minimum_required(VERSION 3.2)
project(gcov_test)
find_package(LLVM 7.0.0 REQUIRED CONFIG)
message(STATUS "Found LLVM: ${LLVM_DIR} ${LLVM_PACKAGE_VERSION}")
add_executable(Test
"main.cpp"
)
target_compile_features(Test
PUBLIC cxx_std_17
)
target_include_directories(Test
PUBLIC ${LLVM_INCLUDE_DIRS}
)
target_compile_definitions(Test
PUBLIC ${LLVM_DEFINITIONS}
)
if(LINK_WITH_LLVM)
# #TODO - cfati: Everything in this block is to avoid hardcoding default libgcc path (/usr/lib/gcc/x86_64-linux-gnu/7)
set(_COLLECT_LTO_WRAPPER_TEXT "COLLECT_LTO_WRAPPER=")
execute_process(
COMMAND bash -c "$0 -v 2>&1 | grep ${_COLLECT_LTO_WRAPPER_TEXT} | sed s/${_COLLECT_LTO_WRAPPER_TEXT}//" "${CMAKE_CXX_COMPILER}"
OUTPUT_VARIABLE _GAINARIE_COLLECT_TMP_VAR
)
get_filename_component(_GAINARIE_GCC_DEFAULT_PATH ${_GAINARIE_COLLECT_TMP_VAR} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L${_GAINARIE_GCC_DEFAULT_PATH}")
#set (GCCOPT "${GCCOPT} -L${_GAINARIE_GCC_DEFAULT_PATH}")
# #TODO END
target_link_libraries(Test
PUBLIC LLVMCore
)
endif()
Note: I tried to come up with something more elegant (I'm sure that it is), but I couldn't (tried using CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES, target_link_libraries, link_directories and a few more) at this point.

Related

Compiling GCC 6.1 on Ubuntu 16.04

Command I have used the following commands to build GCC 6.1:
sudo apt-get -y install libmpfr-dev libgmp3-dev libgmp-dev libmpc-dev flex bison libisl-dev
wget http://nl.mirror.babylon.network/gcc/releases/gcc-6.1.0/gcc-6.1.0.tar.bz2 -O - | tar xjvf -
cd gcc-6.1.0
./configure --enable-shared --disable-checking --enable-languages=c,c++ --disable-multilib
make -j4
When trying to compile GCC 6.1 on Ubuntu 16.04 / x86_64 I get the following error.
libtool: link: /home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc/xgcc -shared-libgcc -B/home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc -nostdinc++ -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib /usr/lib/x86_64-linux-gnu/crti.o /home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -lm -L/home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -lc -lgcc_s /home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc/crtendS.o /usr/lib/x86_64-linux-gnu/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22
/usr/bin/ld: ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o): relocation R_X86_64_PC32 against symbol `_ZTCSt18basic_stringstreamIwSt11char_traitsIwESaIwEE16_St13basic_ostreamIwS1_E' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:606: recipe for target 'libstdc++.la' failed
make[6]: *** [libstdc++.la] Error 1
make[6]: Leaving directory '/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src'
The problematic line seems to be this one:
/usr/bin/ld:
../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o):
relocation R_X86_64_PC32 against symbol
`_ZTCSt18basic_stringstreamIwSt11char_traitsIwESaIwEE16_St13basic_ostreamIwS1_E'
can not be used when making a shared object; recompile with -fPIC
It says recompile with -fPIC, but I can't seem to find the ./configure flag which makes sure libc++11convenience gets built with -fPIC.
I have been searching for a solution, but couldn't find anything. What should I do at this point to successfully compile gcc6.1?
Read carefully the GCC install instructions. GCC should not be built inside its source tree:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree.
You should try again, perhaps something like:
wget \
http://nl.mirror.babylon.network/gcc/releases/gcc-6.1.0/gcc-6.1.0.tar.bz2 -O - \
| tar xjvf -
mkdir Gcc6BuildTree
cd Gcc6BuildTree
../gcc-6.1.0/configure --enable-shared --disable-checking \
--enable-languages=c,c++ --disable-multilib --program-suffix=-6
make -j4
BTW, try first /usr/bin/gcc -v; that will give you how the system compiler was configured & built. And it is inspirational.
Also, I strongly recommend using --program-suffix= (and I would recommend configuring also the GCCJIT)
And you might try first to run aptitude build-dep gcc-6 (or gcc-5) to get the useful dependencies (dependencies for GCC 6 have much in common with dependencies for GCC 5).
Perhaps your Ubuntu already ships with some gcc-6? Did you try aptitude install gcc-6 ? See also this answer.
Also GCC 6.2 was released a few weeks ago (in august 2016). You'll better build gcc 6.2 instead of gcc 6.1
Notice also that the source tarball has a contrib/download_prerequisites script which you might find useful.
NB: gcc-help#gcc.gnu.org might be a better place to ask your question.

Understanding LD under MSYS2

I'm trying to compile the simavr project from https://github.com/buserror/simavr on Windows 10 using MSYS2 and mingw-w64.
After editing the makefiles to enable the MSYS clauses (Which are commented out by default), and changing the order of 2 include files, I can get the project to compile. I do however encounter an error in the linking step.
The output is
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Editing the makefile to print the ${LDFLAGS}, yield the following.
-L/lib -L/local/lib -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
Looking in the folder "obj-i686-w64-mingw32" mentioned in the build script, the file "libsimavr.a" is present. If I copy the file to the msys lib folder the linking step works fine.
The folder structure of the project is as follows:
simavr root (Where i run the makefile from, located in /c/Users/University/GitHub)
simavr
obj-i686-w64-mingw32
As far as I can tell, LD should be able to link properly without me copying the file manually. What am I missing here?
Edit:
The final command before the linker error.
cc -MMD -Werror -O2 -Wall -g -I/usr/local/include -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/lib -L/local/lib -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
Edit 2:
Cleaning the include paths of MSYS folders:
cc -MMD -Werror -O2 -Wall -g -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Passing CC=gcc to make:
gcc -MMD -Werror -O2 -Wall -g -DNO_COLOR -o obj-i686-w64-mingw32/run_avr.elf obj-i686-w64-mingw32/run_avr.o -L/c/Users/University/GitHub/simavr/simavr/../simavr/obj-i686-w64-mingw32 -lsimavr -lelf -lws2_32
C:/Programs/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsimavr
Edit 3:
Output of the find command:
$ find /c/Users/University/GitHub/simavr -name 'libsimavr.a'
/c/Users/University/GitHub/simavr/simavr/obj-i686-w64-mingw32/libsimavr.a
Note that previous entries have been made using the git bash prompt, not the one from msys2. However, running the same commands in the msys2 prompt or the mingw prompt from msys2 yields the same results.
Using mingw-w64 toolchain to build project you MUST remove from CFLAGS/CXXFLAGS/CPPFLAGS all paths with /usr, /local, /lib, /include as this paths can contain headers and libs from MSYS2 itself. Second, try pass "CC=gcc" to makefile.

Linking CUDA + plain C++ code: undefined reference to `__fatbinwrap_66_tmpxft_ etc

Somehow my CUDA binary build process has been messed up. All of the .cu files compile nicely to .o files, but when I try to link, I get:
CMakeFiles/tester.dir/tester_intermediate_link.o: In function `__cudaRegisterLinkedBinary_66_tmpxft_00007a5f_00000000_16_cuda_device_runtime_compute_52_cpp1_ii_8b1a5d37':
/tmp/tmpxft_00006b54_00000000-2_tester_intermediate_link.reg.c:7: undefined reference to `__fatbinwrap_66_tmpxft_00007a5f_00000000_16_cuda_device_runtime_compute_52_cpp1_ii_8b1a5d37'
Now, I have not used compute_52 anywhere. My nvcc command-line is:
/usr/local/cuda/bin/nvcc -M -D__CUDACC__ /home/joeuser/src/my_project/src/kernel_specific/elementwise/Add.cu -o /home/joeuser/src/my_project/CMakeFiles/tester.dir/src/kernel_specific/elementwise/tester_generated_Add.cu.o.NVCC-depend -ccbin /usr/bin/gcc-4.9.3 -m64 --std c++11 -D__STRICT_ANSI__ -Xcompiler ,\"-Wall\",\"-g\",\"-g\",\"-O0\" -gencode arch=compute_35,code=compute_35 -g -G --generate-line-info -DNVCC -I/usr/local/cuda/include -I/opt/cub -I/usr/local/cuda/include
and my link line is:
/usr/bin/g++-4.9.3 -Wall -std=c++11 -g some.o files.o here.o blah.o blahblah.o bar.cu.o baz.cu.o -o bin/myapp -rdynamic -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -lrt -ldl /usr/lib/libboost_system.so /usr/lib/libboost_program_options.so -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -lrt -ldl /usr/local/cuda/extras/CUPTI/lib64/libcupti.so -lnvToolsExt -lOpenCL /usr/lib/libboost_system.so /usr/lib/libboost_program_options.so /usr/local/cuda/extras/CUPTI/lib64/libcupti.so -lnvToolsExt -lOpenCL -Wl,-rpath,/usr/lib:/usr/local/cuda/extras/CUPTI/lib64
I'll note I have separate compilation enabled, and do not seem to have skipped my intermediate link phase.
Why is this happening?
CUDA has two compilation modes, relocatable and static.
The relocatable mode is required for some configurations-which we will not get into now.
If you want to compile in relocatable mode -rdc=true, you'll need the Cuda device runtime library.
Which is located in the file cudadevrt.lib.
On some instances, supplying -lcudadevrt as a command line switch to the CUDA linker does the job, but on e.g. MSVC, you'll also need to specify cudadebrt.lib as a link dependency.
Well, I'm not sure why I'm seeing missing references to Compute 5.2 calls, but adding -lcudadevrt to the end of the link command makes the error go away.

(clang / llvm-mc / lld) hello world (x86-64 windows & linux)

Is llvm able to compile, assemble and link x86-64 code on windows and/or linux using llvm-mc and lld?
If so, is there a hello-world level example out there? The documentation is pretty sparse at present.
I've tried building a simple hello world (main0.cpp) using trunk LLVM (with clang & lld).
main0.cpp:
int main(int argc, char const* argv[])
{ return 0; }
Compile (no errors):
[MY-LLVM]/clang -S -o main0.s main0.cpp
Assemble (no errors):
[MY-LLVM]/llvm-mc -arch=x86-64 -triple=x86_64-linux-gnu -o main0.o main0.s
Link (FAILS HERE!):
[MY-LLVM]/lld -flavor gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib -L/<MY-LLVM>/lib -L/lib -L/usr/lib -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o -o main0.run main.o
Link error:
lld: unknown input file format for file main.o
I obtained the linker command via clang -o main0.run main0.cpp -### (replacing ld with [MY-LLVM]/lld -flavor gnu).
I assume that I'm either generating the wrong type of object file when assembling, or using the wrong parameters when linking.
Does anyone know how to do this right?
(My ultimate aim is to get full C++14 working on win64 (without massive hacks), but I'm struggling with getting trunk clang to work with the mingw tools so I thought I'd try pure LLVM).
lld developer here.
lld self hosts on both Linux and Windows, so I would expect them to work here. The way I generally get clang to use lld is to make a symlink to lld named ld and add it to PATH. lld will behave like gnu-ld in this case.
As for llvm-mc, it is not an assembler. It is a tool for testing the MC layer of llvm. By default it simply parses the assembly and prints it back out. This is why lld is rejecting the main0.o file, as it's actually a text file.
The correct thing to do here without having lld as ld in the path is either:
clang -c -o main0.o main0.cpp
or:
clang -S -o main0.s main0.cpp
clang -c -o main0.o main0.s
If you really want the assembly for some reason.

How to build Qt 5.1 for QNX target (arm)

new update
I think I should edit the title now.
To make sure I got a clean environment, I
download qt5.1.1 src code from qt-prject.
export QNX_TARGET, QNX_HOST, AND add QNX_HOST into PATH.
then Run the script
./configure -opensource -confirm-license -xplatform qnx-armv7le-qcc -v
so in here, -opensource -confirm-license just avoid the Q&A -v is to show full message.
a lot of error message.
Creating qmake...
make: Nothing to be done for `first'.
Running configuration tests...
Determining architecture... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -g -Wall -W -fPIE -DQT_NO_CLIPBOARD -I../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o arch.o arch.cpp
Unable to determine architecture!
Could not determine the target architecture!
Turn on verbose messaging (-v) to see the final report.
Determining architecture... ()
g++ -c -pipe -g -Wall -W -fPIE -I../../mkspecs/linux-g++ -I. -o arch.o arch.cpp
g++ -o arch arch.o { test -n "" && DESTDIR="" || DESTDIR=.; } && test $(gdb --version | sed -e 's,[^0-9]\+\([0-9]\)\.\([0-9]\).*,\1\2,;q') -gt 72 && gdb --nx --batch --quiet -ex 'set confirm off' -ex "save gdb-index $DESTDIR" -ex quit 'arch' && test -f arch.gdb-index && objcopy --add-section '.gdb_index=arch.gdb-index' --set-section-flags '.gdb_index=readonly' 'arch' 'arch' && rm -f arch.gdb-index || true
Found architecture in binary
CFG_HOST_ARCH="x86_64"
CFG_HOST_CPUFEATURES=" mmx sse sse2"
System architecture: 'unknown'
Host architecture: 'x86_64'
C++11 auto-detection... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wc,-std=gnu++0x -Wall -W -fPIE-DQT_NO_CLIPBOARD -I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o c++11.o c++11.cpp
C++11 disabled.
floatmath auto-detection... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wall -W -fPIE -DQT_NO_CLIPBOARD-I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o floatmath.o floatmath.cpp
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wall -W -fPIE -DQT_NO_CLIPBOARD -I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o freetype.o freetype.cpp
FreeType disabled.
STL auto-detection... ()
qcc -Vgcc_ntoarmv7le -c -Wno-psabi -lang-c++ -O2 -Wall -W -fPIE -DQT_NO_CLIPBOARD -I../../../mkspecs/qnx-armv7le-qcc -I. -I/opt/qnx650/target/qnx6/usr/include -I/opt/qnx650/target/qnx6/usr/include/freetype2 -o stltest.o stltest.cpp
STL disabled.
STL functionality check failed! Cannot build Qt with this STL library.
Turn on verbose messaging (-v) to /home/pasadeveloper/qt-everywhere-opensourcesrc-5.1.1/qtbase/configure to see the final report.
UPDATE:
I am working on QNX for ARM, target is an arm platform device.
Thing is getting weird. in Env Var, I put
$QNX_CONFIGURATION=/etc/qnx
$QNX_JAVAHOME=/opt/qnx650/_jvm
$QNX_TARGET=/opt/qnx650/target/qnx6
$QNX_HOST=/opt/qnx650/host/linux/x86
but when I do qmake qmake.conf mkspecs/qnx-armv7le-qcc folder
it returns an error message Project ERROR: QNX_TARGET environment variable not set
Have no clue what is going on now.
not just qmake qmake.conf
I try to build qt 5.1.2 at another host, ubuntu 12.04-64bit.
also get the same error message. Project ERROR: QNX_TARGET environment variable not set
I was working at Qt development under linux(FYI Ubuntu 12.04 -64bits), but I need to compile this program to binary for QNX.
I install QNX MOmentics IDE which provide QNX-gcc for me.
but I can't find the qmake-qnx.
Under the QT/gcc_64/mkspecs/qnx-armv7le-qcc, there is a file call qmake.conf. I guess this is where I can generate my qmake-qnx. after I run qmake -o Makefile qmake.conf, there is a Makefile generated.
However, when I run make, error occured.
qcc -Vgcc_ntoarmv7le -lang-c++ -Wl,-rpath-link,/opt/qnx650/target/qnx6/armle-v7/lib -Wl,-rpath-link,/opt/qnx650/target/qnx6/armle-v7/usr/lib -Wl,-O1 -Wl,-O1 -Wl,-rpath,/home/pasadeveloper/Qt5.1.0/5.1.0/gcc_64 -Wl,-rpath,/home/pasadeveloper/Qt5.1.0/5.1.0/gcc_64/lib -o qmake -L/opt/qnx650/target/qnx6/armle-v7/lib -L/opt/qnx650/target/qnx6/armle-v7/usr/lib -lm -L/home/pasadeveloper/Qt5.1.0//5.1.0/gcc_64/lib -lQt5Gui -lQt5Core -lGL -lpthread
cc: no files to process
make: *** [qmake] Error 1
pasadeveloper#ubuntu:~/Qt5.1.0/5.1.0/gcc_64/mkspecs/qnx-armv7le-qcc$
You do not "generate" your qmake-qnx like that. You are supposed to use the native qmake for generating proper makefiles for your target to aid the cross-compilation. Also, running qmake qmake.conf in the relevant mkspecs folder is wrong because that is not a project file as you may think.
When building Qt itself for instance, you should be using the proper mkspecs files for the target in which case, it is the one you also mentioned above if it is built for that particular arm qnx variant, called qnx-armv7le-qcc.
Here is the exact command you need to run after downloading the relevant Qt sources, like 5.1.1:
./configure -opensource -confirm-license -xplatform qnx-armv7le-qcc -v
For this QNX version, the bottom line is, if you do not have SP1 and libscreen, it will not work. The QPA plugin would link against it. This library provides the API to the graphics server on newer QNX variants. You need to talk to your QNX representatives.
Here you can find further information about the topic.
$QNX_TARGET=/opt/qnx650/target/qnx6
is probably not doing what you want. In shell scripts, you don't put a "$" in front of a variable when you are defining the variable, only when you access the variable:
X=hello
echo $X