I successfully built standalone llvm on windows with clang-cl (clang 8.0 downloadable binary) against back-end msvc build tool 2017 with windows 10 sdk using cmake/ninja
After that when I was building standalone clang, it reported "version.lib" in linking phase of clang-rename.exe is missing.
LINK Pass 1: command "....
" failed (exit code 1104) with the following output:
LINK : fatal error LNK1104: cannot open file 'version.lib'
The weird thing is that word version.lib was slabbed in place amoung various lib\clang?????.libs and the leading -LIBPATH:llvm\\.\lib
I tried looking for version.lib in both build folders of llvm and clang, and found none.
Am I supposed to have verson.lib in llvm\lib?
What am I missing here?
Related
I want to compile a golang program containing CGO code into a program running under Linux under windows, and I encountered the following error at the beginning
fatal error: Windows.h: No such file or directory
After that I copied the content under mingw64\x86_64-w64-mingw32\include to the x86_64-linux-musl\x86_64-linux-musl\include directory
I am using GCC under x86_64-linux-musl to build the program, the version is
Proceed to build with error #error Only Win32 target is supported!
I've been searching for a long time and haven't found a solution
I have just successfully built llvm, clang and lld on msvc build tool 2017 with windows 10 sdk.
I tried to build libcxx next.
While I was doing cmake/ninja (with clang-cl of newly built clang), I got this:
CMake Error at test/CMakeLists.txt:72 (include):
include could not find load file:
AddLLVM
CMake Error at test/CMakeLists.txt:74 (configure_lit_site_cfg):
Unknown CMake command "configure_lit_site_cfg".
-- Configuring incomplete, errors occurred!
I did also pass this parameter to cmake
-DLLVM_PATH="C:/llvm"
Is this because I built llvm wrong?
UPDATE
I already fixed this by
-DCMAKE_MODULE_PATH="C:/llvm-master/cmake/modules
I'm working on a Linux machine (debian) 64bit and created a simple project involving JNI. The program is running fine on Linux with the created Java project and the compiled .so file. The goal now is to compile the C++ part of the project into a .dll instead of a .so to get it to run on Windows machines.
I read some forums and some articles like this one Article, but all of those articles were about compiling from console and also didn't involve the necessary JNI includes.
I also downloaded the cross-compiler from the given article and tried to get it to run in Netbeans. Therefore I set up another C/C++ Tool Collection in Netbeans and told it to use the x86_64-w64-mingw32-gcc compiler for both C and C++. But Netbeans is giving me some errors compiling the file, telling me the x86_64-w64-mingw32-gcc compiler could not be found which is quite random I think because I selected it from the file chooser. Did any of you do something like this already, building a .ddl from Netbeans running on Linux? If yes, how did you get it to work?
x86_64-w64-mingw32-gcc: not found
bproject/Makefile-Debug.mk:66: recipe for target 'build/Debug/GNU_1-Linux-x86/WrapperCpp.o' failed
make[2]: *** [build/Debug/GNU_1-Linux-x86/WrapperCpp.o] Error 127
make[2]: Leaving directory
nbproject/Makefile-Debug.mk:59: recipe for target '.build-conf' failed
make[1]: *** [.build-conf] Error 2
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make: *** [.build-impl] Error 2
#Edit: I'm a step further now: I installed the correct mingw32 tools: sudo apt-get install mingw32. The programm does now compile without errors using the i586-mingw32msvc-g++ compiler but it still results in a .so instead of a .dll. I guess it has something to do with the make command but I haven't found anything about that yet.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
I have just recently started running Linux on my PC and I am trying to start learning OpenGL. I am using the latest version of Eclipse CDT as my IDE, and my system is Ubuntu 10.10, 64 bit version.
The problem I am having is that whenever I try to run a build from within the IDE I get the error message "Launch Failed. Binary Not Found."
Ive done a lot of looking around on the internet but I still cant solve the problem. I know for a fact that the binary is built, it can be run from a terminal window. According to posts I have seen the problem is that Eclipse tries to run a 32 bit binary, but GCC 4.4.5 defaults to 64 bit binaries on a 64 bit system.
* Edit * This is where I gathered the above information
Ive seen a lot of information about using the -m32 flag in makefiles, but then I still get the following output in Eclipse:
make all
g++ -o HelloWorld2 main.o
/usr/bin/ld: i386 architecture of input file `main.o' is incompatible with i386:x86-64 output
/usr/bin/ld: final link failed: Invalid operation
collect2: ld returned 1 exit status
make: *** [HelloWorld2] Error 1
What I would like to know is how to either get Eclipse to launch the 64 bit binaries, or have Eclipse correctly compile 32 bit binaries.
(I was able to reproduce the error you describe, so my answer is based on 'reverse-engineering' the error).
In the eclipse projects pane, right-click the project and go to 'properties'. Under C/C++ Build -> Settings, click the Binary Parsers tab, and verify that Elf Parser is checked. (I am not sure if it needs to be the only checked parser).
Btw, you can verify the class of your binary file using readelf -h myBinary.o and looking at the Class field.
Regarding running the 32-bit binary, maybe this post is helpfull: http://stefaanlippens.net/32bit_executable_on_64bit_machine