Mikael Lyngvig
2012-Jun-11 08:53 UTC
[LLVMdev] Clang64 on Windows using Mingw64 yields many linking errors?
Hi again, I am regularly building my small STL-enabled C++ project using Mingw64 on Windows x64 and the program runs fine (it builds and runs fine on x64 Linux too). Then I got brave and decided to try out Clang, because I'd eventually like to take a look at the quality of the generated code, and then did the following: 1. Set CC to clang. 2. Set CXX to clang++. 3. Run cmake and let it figure out that its using Clang on Windows. 4. Build and realize that the link doesn't work because CMake pulls in the wrong libraries (per default it uses Microsoft naming conventions: foo.lib instead of libfoo.a). 5. Search good old Google and find this VERY helpful article: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/42398 6. Fix CMake as per the above. 7. Build and realize that the CMake pulls in the right libraries but still a torrent of errors are reported: ..\libBackend.a(Backend.cpp.obj):fake:(.rdata$ZTIN10Braceless07BackendE+0xffffffffff6e88a0): Cannot get section contents - auto-impo rt exception ..\libBackend.a(Backend.cpp.obj):fake:(.data+0xfffffffffffffd00): Cannot get section contents - auto-import exception ..\libDriver.a(Setup.cpp.obj):fake:(.text$ZNSt6vectorISsSaISsEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPSsS1_EERKSs+0xffffffffffffb34d): Cannot get section contents - auto-import exception ..\libDriver.a(Setup.cpp.obj):fake:(.text$ZNSt6vectorISsSaISsEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPSsS1_EERKSs+0xffffffffffffb42e): Cannot get section contents - auto-import exception ..\libDriver.a(Setup.cpp.obj):fake:(.text$ZNSt6vectorISsSaISsEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPSsS1_EERKSs+0xffffffffffffb458): Cannot get section contents - auto-import exception ..\libDriver.a(Setup.cpp.obj):fake:(.text$ZNSt6vectorISsSaISsEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPSsS1_EERKSs+0xffffffffffffb59a): Cannot get section contents - auto-import exception ..\libDriver.a(Setup.cpp.obj):fake:(.text$ZNSt6vectorISsSaISsEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPSsS1_EERKSs+0xffffffffffffb5c5): Cannot get section contents - auto-import exception ..\libDriver.a(Setup.cpp.obj):fake:(.text$ZNSt20__uninitialized_copyILb0EE13__uninit_copyIPSsS2_EET0_T_S4_S3_+0xffffffffffff6203): Cannot get section contents - auto-import exception Is it because Clang does not support the Mingw64 ABI? I was under the impression that Clang DID support the Mingw32/64 toolchains, but perhaps it is only the 32-bit version? Cheers, Mikael -- Love Thy Frog! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120611/d85dfefa/attachment.html>
Anton Korobeynikov
2012-Jun-11 11:04 UTC
[LLVMdev] Clang64 on Windows using Mingw64 yields many linking errors?
Hello First of all, note the "llvm" in the mailing list title. Clang questions should be asked in other ML.> 3. Run cmake and let it figure out that its using Clang on Windows. > 4. Build and realize that the link doesn't work because CMake pulls in the > wrong libraries (per default it uses Microsoft naming conventions: foo.lib > instead of libfoo.a).It seems like you're not targeting mingw32, but MS toolchains. Stuff won't work smooth here and major WIP. Everything else below can be ignored. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Justin Holewinski
2012-Jun-11 11:34 UTC
[LLVMdev] Clang64 on Windows using Mingw64 yields many linking errors?
On Mon, Jun 11, 2012 at 7:04 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote:> Hello > > First of all, note the "llvm" in the mailing list title. Clang > questions should be asked in other ML. >(Cross-posting to cfe-dev)> > > 3. Run cmake and let it figure out that its using Clang on Windows. > > 4. Build and realize that the link doesn't work because CMake pulls in > the > > wrong libraries (per default it uses Microsoft naming conventions: > foo.lib > > instead of libfoo.a). > It seems like you're not targeting mingw32, but MS toolchains. Stuff > won't work smooth here and major WIP. > Everything else below can be ignored. >I don't think that's the issue here. CMake happily tries to link with the mingw libs, but as pointed out in that CMake ML post, the CMake scripts do not know how to pass GCC-style flags to Clang on Windows. Mikael, can you post the link line that CMake generates (make VERBOSE=1), preferably to just cfe-dev?> > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120611/35bff367/attachment.html>
Mikael Lyngvig
2012-Jun-11 11:38 UTC
[LLVMdev] Clang64 on Windows using Mingw64 yields many linking errors?
Ouch, sorry, forgot about that other list. I'll repost my question there. I am NOT using the MS toolchain, though. Cheers, Mikael -- Love Thy Frog! 2012/6/11 Anton Korobeynikov <anton at korobeynikov.info>> Hello > > First of all, note the "llvm" in the mailing list title. Clang > questions should be asked in other ML. > > > 3. Run cmake and let it figure out that its using Clang on Windows. > > 4. Build and realize that the link doesn't work because CMake pulls in > the > > wrong libraries (per default it uses Microsoft naming conventions: > foo.lib > > instead of libfoo.a). > It seems like you're not targeting mingw32, but MS toolchains. Stuff > won't work smooth here and major WIP. > Everything else below can be ignored. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120611/6c81cd55/attachment.html>