I was trying to build Mesa 22.0.0 with the latest LLVM installed, if Mesa is also the latest version then the building process works fine. I was building Mesa 22.0.0, but the latest LLVM headers contain some C++ code that is not supported in older Mesa, but Mesa source file includes those headers, which causes the building process failed. Next, I tried to check out LLVM to some older version like 13.0.0, most of the compiling errors are gone except some linking errors about some undefined reference to LLVM functions. Anyone knows how to solve this kind of issue?
Related
I've recently downloaded and successfully compiled a small CUDA dll using NVCC (10.2). Unfortunately because I have the most recent toolkit version the distribution requires the most recent driver version too. So I was wondering if there was an NVCC flag that enabled me to effectively target an earlier driver version and then distribute with an older runtime.
Currently, I have to check the run time and driver versions in order to check for compatibility.
The CUDA toolchain, runtime API and its support libraries are versioned and if you build runtime API code with a given toolkit version, you must ship the resulting code with all the libraries from that version or have users install that toolkit version (aka the tensorflow problem).
If you use the driver API, then you can potentially target a lower compute capability with PTX which might be backward compatible with a different driver. I say might because there are still PTX version support limits which can stop it from working correctly.
If you want to support older CUDA versions, just install the older toolchain and build using that toolkit.
I'm trying to build OpenCV in Windows 7 with Clang 5.0.0 but Cmake does not recognize the option and, therefore, there is no compilation available.
The system contains Clang 5.0.0, MSVC 2013 Express and Cmake 3.10.0.
Googling the solution does not show any valid results.
There is any way to generate the OpenCV dll/lib with Clang (and LLVM) capabilites/dependencies?
If there is a workaround evading MSVC, I accept it, too.
Thanks in advance.
[Situation]
I'm developing a c++ library. I had a issue with the GLIBCXX version.
Before, I developed on version machine GLIBCXX_3.4.22.
But my library is not working on the target machine which has GLIBCXX_3.4.19.
So, I downgraded gcc version from 5.2.x to 4.8.x and GLIBCXX version from 3.4.22 to 3.4.19.
It successfully ran on the target machine.
But my development machine(ubuntu) boot fails because other libraries can't find GLIBCXX 3.4.22 version which is already linked to that version.
So, I re-installed GLIBCXX 3.4.22 but gcc version is still 4.8.5.
[Question]
Does my library compiled on gcc-4.8.5 not use GLIBCXX_3.4.22 version? Is it fine to develop on this environment (gcc 4.8.5, GLIBCXX_3.4.22)?
What is the relationship between gcc(compile) version and GLIBCXX(GLIBC) version on the linux machine.
Where can I check the correct version compatibility mapping information between gcc and GLIBCXX(GLIBC)?
libstdc++ (which is where the GLIBCXX_* versioned symbols are from) has been ABI compatible from GCC 3.4.0 to now.
Your library will use the latest symbol versions from libstdc++ at the time of compile. The compiler version does not matter, except
GCC 5.1 added C++11 support with a "dual ABI" in libstdc++. Code compiled in C++11 mode will use symbols with the [abi:cxx11] tag, and that may not interoperate with code compiled without C++11 (whether from an older compiler without C++11 support, or a newer compiler set to use an older standard).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
If you need to build binaries that run on older systems, I would recommend setting up an older distribution inside a container and building in there, with all old libraries. This way, nothing newer from your development system can leak into them.
Good day all
I have been searching for a method of cross-compiling for QT-Creator in Linux for sometime now, and I have been having alot of trouble with it.
Background info
please note: I am on a Linux machine, and would like to cross compile Windows Apps
My system:
Ubuntu Gnome 16.10
QT Creator 4.0.2 (based on QT 5.7)
I have came across a few SO links, a few blogs with broken instructions, etc and one seeming helpful but dependencies could not be found.
I have also attempted another compiler MXE and cloned and attempted to build the MXE compiler from the GIT repo, which failed (no solution for the build error - VTK build error)
I decided to download precompiled MinGW compilers (i686 and x86_x64 versions) from sourceforge
Issue:
In QT Creator, adding the compiler is done without an issue, adding the "Kit" and selecting the newly added compiler, an red exclamation gives an error
The Compiler (x86_windows_msys_pe_64bit) cannot produce code for QT version 5.7.0 GCC 64Bit (x86_linux_generic_elf_64bit)
This occurs for both 32 + 64 bit compilers.
I think that you should have a QT version that matches your compiler ABI. The error tells you that the MinGW compiler doesn't match the Linux version of QT you have used. Therefore, get a windows version of QT and use it instead (just as you've added WinGW).
You can download Qt Binaries from here.
I need to build KLEE on my Ubuntu 12.04. I followed KLEE website's instructions step by step. I had LLVM 2.9 built. But when I need to install klee-uclibc, and in the process of configuring, it complained that it failed to find a working LLVM bitcode compiler. Does this mean that my LLVM built was unsuccessful? I am new to Linux and new to the testing tool. Any help is greatly appreciated.
I ran into the same problem, but a closer look in klee document helped me fix it. Especially look at step (02)(01):
Install llvm-gcc:
Download and install the LLVM 2.9 release of llvm-gcc from here. On an x86-64 Linux platform you are going to need the archive LLVM-GCC 4.2 Front End Binaries for Linux x86-64.
Add llvm-gcc to your PATH. It is important to do this first so that llvm-gcc is found in subsequent configure steps. llvm-gcc will be used later to compile programs that KLEE can execute. Forgetting to add llvm-gcc to your PATH at this point is by far the most common source of build errors reported by new users.
Hence, make sure that llvm-gcc is installed and a PATH is provided to the executable.