search for: gtest_main

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py...

...llvm_executable(${test_name} IGNORE_EXTERNALIZE_DEBUGINFO ${ARGN}) set(outdir ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}) set_output_directory(${test_name} BINARY_DIR ${outdir} LIBRARY_DIR ${outdir}) + if (LLVM_LINK_LLVM_DYLIB) + target_link_libraries(${test_name} + gtest + gtest_main + ) + else() target_link_libraries(${test_name} - gtest - gtest_main - LLVMSupport # gtest needs it for raw_ostream. - ) + gtest + gtest_main + LLVMSupport # Depends on llvm::cl + ) + endif() add_dependencies(${test_suite} ${test_name}) get_target_pr...

...ts.txt file for building the C > code. > > Problem is, cmake no longer finishes at all. I receive the > following output, and then it just runs forever (while still > responding to a CTRL-C): Yep, llvm_map_components_to_libraries gets confused by the existence of both gtest and gtest_main and enters an infinite loop. A workaround is to not pass "all" to llvm_map_components_to_libraries but a list of required components.

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

...sults. Furthermore, the undefined references are thousands! If you say that libc++ is not need it how can I skip it's interference. Shall I check out the package again without the particular libc++, of invoke cmake with a particular parameter? . . [ 52%] Built target gtest [ 52%] Built target gtest_main Linking CXX shared library ../../../lib/libc++.so CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::iostream_category()': /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to `__cxa_guard_acquire' /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference...

...ic #39-Ubuntu SMP x86_64 GNU/Linux. I essentially intend to use the clang static analyzer, but it seems that I have to build it on top of llvm and clang. Unfortunately I run into the following problem. CXX shared library ../../../lib/libc++.so at around 52% of the procedure (while building target gtest_main) followed by a handful of undefined references the last lines consist of the following messages: collect2: error: ld returned 1 exit status projects/libcxx/lib/CMakeFiles/cxx.dir/build.make:735: recipe for target 'lib/libc++.so.1.0' failed make[2]: *** [lib/libc++.so.1.0] Error 1 CMakeFile...

...eferences are thousands! > If you say that libc++ is not need it how can I skip it's interference. Shall I check out the package again without the particular libc++, of invoke cmake with a particular parameter? > > > . > . > [ 52%] Built target gtest > [ 52%] Built target gtest_main > Linking CXX shared library ../../../lib/libc++.so > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function `std::__1::iostream_category()': > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to `__cxa_guard_acquire' > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71:...

Hi again, I'm trying to upgrade my LLVM bindings in Java from 2.9 to 3.1. To do so, I regenerated the JNI bindings from fresh LLVM 3.1 headers, and did a slight rewrite of my CMakeLists.txt file for building the C code. Problem is, cmake no longer finishes at all. I receive the following output, and then it just runs forever (while still responding to a CTRL-C): > eli at

...inux. > > I essentially intend to use the clang static analyzer, but it seems that I have to build it on top of llvm and clang. > > Unfortunately I run into the following problem. > CXX shared library ../../../lib/libc++.so > at around 52% of the procedure (while building target gtest_main) > followed by a handful of undefined references > > the last lines consist of the following messages: > collect2: error: ld returned 1 exit status > projects/libcxx/lib/CMakeFiles/cxx.dir/build.make:735: recipe for target 'lib/libc++.so.1.0' failed > make[2]: *** [lib/li...

...s are thousands! > If you say that libc++ is not need it how can I skip it's interference. > Shall I check out the package again without the particular libc++, of > invoke cmake with a particular parameter? > > > . > . > [ 52%] Built target gtest > [ 52%] Built target gtest_main > Linking CXX shared library ../../../lib/libc++.so > CMakeFiles/cxx.dir/__/src/ios.cpp.o: In function > `std::__1::iostream_category()': > /opt/llvm/llvm/projects/libcxx/src/ios.cpp:71: undefined reference to > `__cxa_guard_acquire' > /opt/llvm/llvm/projects/libcxx/src/io...

Óscar Fuentes <ofv at wanadoo.es> writes: > Yep, llvm_map_components_to_libraries gets confused by the existence of > both gtest and gtest_main and enters an infinite loop. A workaround is > to not pass "all" to llvm_map_components_to_libraries but a list of > required components. This patch *seems* to fix the problem (cmake regexps are not thoroughly documented): --- a/cmake/modules/LLVM-Config.cmake +++ b/cmake/modules/...

...\program files (x86)\microsoft visual studio\2017\community\VC\Tools\MSVC\14.10.25017\include\xmemory(126): error C2062: type 'unknown-type' unexpected gtest.vcxproj -> C:\Users\andy\AppData\Local\CMakeBuild\12c242dd-f206-c033-afac-74b8717657f2\build\x86-Debug\Debug\lib\gtest.lib gtest_main.vcxproj -> C:\Users\andy\AppData\Local\CMakeBuild\12c242dd-f206-c033-afac-74b8717657f2\build\x86-Debug\Debug\lib\gtest_main.lib Generating ../../bin/scan-build.bat Generating ../../libexec/ccc-analyzer.bat Generating ../../libexec/c++-analyzer.bat Generating ../../share/man/man1/...

I'm so close to having LLVM build on PowerPC. If there's any PowerPC experts, help? Lines like this: outs() << "[" << format("%2d", i) << "]" << "(sec " << format("%2d", int16_t(symbol->SectionNumber)) << ")" << "(fl 0x" <<

On Apr 8, 2013, at 2:55 PM, "Robinson, Paul" <Paul_Robinson at playstation.sony.com> wrote: I keep seeing "this is a layering violation" comments on the lists. > While there are a few llvm.org pages that mention layers in passing, > there is nothing (that I've found) actually specifying the layers. > Trying to infer the layering from the code is tedious and

I keep seeing "this is a layering violation" comments on the lists. While there are a few llvm.org pages that mention layers in passing, there is nothing (that I've found) actually specifying the layers. Trying to infer the layering from the code is tedious and error-prone (or we wouldn't see so many violations in code reviews, eh?). Now, I understand that Google has some sort

...itanium-demangle-fuzzer/CMakeFiles/llvm-itanium-demangle-fuzzer.dir 124K build/tools/clang/test/Modules/Output/submodule-visibility.cpp.tmp 124K build/tools/clang/test/CXX/module/module.interface/Output 124K build/tools/clang/test/Analysis/copypaste 120K build/utils/unittest/UnitTestMain/CMakeFiles/gtest_main.dir 120K build/tools/clang/test/Modules/Output/redecl-merge.m.tmp 120K build/tools/clang/test/Modules/Output/no-stale-modtime.m.tmp 120K build/tools/clang/test/CXX/over/over.match 120K build/tools/clang/test/clang-rename 120K build/tools/clang/test/Analysis/copypaste/Output 116K build/tools/clang/t...