The odcctools package provides binutils for the Darwin OS. -- this allows you to cross compile to Darwin and OSX for example. However, odcctools does not seem to build properly on 64-bit OSes:
./../expr.c: In function ‘expression’:
./../expr.c:311: error: ‘union <anonymous>’ has no member named ‘n_name’
Or, if you set CFLAGS to -m32, you get this:
/usr/bin/ld: skipping incompatible ../libstuff/libstuff.a when searching for -lstuff
/usr/bin/ld: cannot find -lstuff
How do you build this on a 64-bit OS?
The way the odcctools makeflags are set up, you can't use CFLAGS -- you have to set both CC and CXX:
CC="gcc -m32" CXX="g++ -m32" ./configure blah blah blah
Note that I had to add a -fpermissive to my CXX to get it to run but this may not be necessary!
Also, you may be interested in this post (although it wasn't sufficient for my setup).
(If anyone has a better way to do this please let me know!)
Related
I have been trying to build BlockFactory and I keep getting following error when trying to build it.
PS F:\simconnect-monitor\blockfactory> cmake -S . -B build
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.19044.
-- The CXX compiler identification is MSVC 19.16.27045.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Matlab (missing: Matlab_MEX_LIBRARY Matlab_MX_LIBRARY ENG_LIBRARY) (found version "9.10")
CMake Error at C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
Could NOT find Matlab (missing: Matlab_MEX_LIBRARY Matlab_MX_LIBRARY MX_LIBRARY) (found version "9.10")
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
cmake/FindMatlab.cmake:1873 (find_package_handle_standard_args)
deps/mxpp/CMakeLists.txt:45 (find_package)
As you can see, MatLab was detected but the correct library cannot be found. I have tried with CMake 3.18.14 and 3.22.3 with no difference. I am really loss right now honestly. I have posted an issue in the BlockFactory GitHub but so far, it is still unresolved.
So, I found the solution. I am using VS2017. By default for VS2017, cmake makes 32-bit project. You have to pass cmake -A x64 to force it to a 64-bit project. In addition to that, though, I have to force finfmatlab.cmake to only look for 64-bit library by basically setting _matlab_64build to always be true. Make sure you have 64-bit MatLab if you do this.
Edit: Alternatively, you can install VS2019 instead since it defaulted to 64-bit project.
I'm setting up a C/C++ build environment on Windows using Eclipse CDT, CMake and the cmake4eclipse plugin. Everything works fine except the generation of compile_commands.json. This file is required by the cmake4eclipse plugin in order to use the two CMAKE_EXPORT_COMPILE_COMMANDS providers for automatic include detection etc. (as far as I understood that correctly).
I'm using Windows builds of CMake (3.20) and ninja as well as the MSYS2 version of gcc. All tools are accessible via the PATH variable (compilation works fine as I already mentioned).
My cmake command roughly looks like this:
cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON -G Ninja "C:\\path\\to\\source"
During configuration I always get the warning
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_EXPORT_COMPILE_COMMANDS
and no compile_commands.json is generated in the build directory.
I understand that this is often a problem when trying to export compile commands for generators which are not supported, e.g. Visual Studio. But since I'm using ninja, I would expect a successful generation of the JSON file.
Did anyone experience similar issues or has any ideas?
Thanks!
Edit:
Here's the output with message(STATUS "gen = ${CMAKE_GENERATOR}"):
cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON -G Ninja "C:\\path\\to\\source"
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/usr/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/usr/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- gen = Ninja
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_EXPORT_COMPILE_COMMANDS
-- Build files have been written to: C:/path/to/build
10:52:57 Buildscript generation finished (took 9351 ms)
Unfortunately I can't post my whole CMakeLists.txt since it belongs to a project in our company. The top-level CMakeLists.txt does not define any targets, but adds a couple of ExternalProjects to support cross-compilation.
I was able to reproduce your error message with the following CMakeLists.txt. This is not a bug:
cmake_minimum_required(VERSION 3.20)
project(test)
I then ran
> cmake -G Ninja -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
-- The C compiler identification is MSVC 19.28.29915.0
-- The CXX compiler identification is MSVC 19.28.29915.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_EXPORT_COMPILE_COMMANDS
-- Build files have been written to: D:/test/build
The reason for this is because, as you say,
The top-level CMakeLists.txt does not define any targets, but adds a couple of ExternalProjects to support cross-compilation.
The commands for custom targets are not included in the compile_commands.json, and the variable is only inspected by CMake when processing the first compiled target (either add_executable or add_library).
There is no simple fix; setting CMAKE_EXPORT_COMPILE_COMMANDS in each of your sub-projects will result in one compile_commands.json file for each. Merging them such that Eclipse will understand the result is beyond the scope of this question.
This is part of a larger issue with ExternalProject -- it's too separated. It boils down to automating the creation of some relatively complicated custom targets and commands, so the parent project has no idea what's going on in its children.
A better approach for cross-compiling with host tools is to allow the user to call your build twice: first with a host toolchain in one directory and second with a target toolchain in a different directory with variables set so that the first build will be scanned for host tools instead of re-creating the targets in the target build. The export() and find_package() commands are useful for this.
I am trying to compile swift-lldb on Ubuntu 14.04 (following instructions from https://github.com/apple/swift-lldb). I have the following dependencies installed:
Clang-3.5
Cmake version 3.5.2
Python version 2.7.6
On running the build script step which is lldb/scripts/build-swift-cmake.py --test, I am seeing the following error:
CMake Warning at cmake/modules/HandleLLVMOptions.cmake:185 (message):
-fPIC is not supported.
Call Stack (most recent call first):
cmake/modules/HandleLLVMOptions.cmake:216 (add_flag_or_print_warning)
CMakeLists.txt:616 (include)
CMake Error at cmake/modules/HandleLLVMOptions.cmake:429 (message):
LLVM requires C++11 support but the '-std=c++11' flag isn't supported.
Call Stack (most recent call first):
CMakeLists.txt:616 (include)
I have defined environment variables CC and CXX to point to the clang C and C++ compilers.
root:/myswift# echo $CC
/usr/bin/clang
root:/myswift# echo $CXX
/usr/bin/clang++
I also found in the clang documentation that c++11 is supported by clang-3.5. Not sure what I am missing here. Can someone please help?
clang-4.0 mentioned as part of the installation should support the -std=c++11 flag (just tested clang-4.0.1). However, upgrading to clang-6.0 seems to solve this build process error.
Running cmake directly in the automatically created build directory (by the swift build scripts) could be used to investigate the build failure in more detail. To specify compilers here, rather than setting CC and CXX environment variables (which works well for GNU configure scripts), compilers can be set for cmake via
cmake -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ path_to_src_or_build_directory
An existing CMakeCache.txt might have to be removed, so that the above parameters are honored.
A problem with clang++ installations that I have observed is that clang++ cannot find C++ headers (i.e. if C++ headers are in non-standard locations other than /usr/include, unlikely in the case of Ubuntu though). In case /usr/bin/clang++ cannot compile a simple program like
#include <iostream>
using namespace std;
int main() {
cout << "hello" << endl;
return 0;
}
not being able to find the iostream include file, it might help to set --gcc-toolchain=/pathtoaworkinggcc, where pathtoaworkinggcc should include include, lib, bin, etc. of a working C++ compiler (possibly g++ in the case of a Ubuntu installation).
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I know this issue already discussed (include there), and no one time. But, unfortunately, I cannot solve this problem.
So, I have OS X Lion, i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1, and I try to build gcc-4.7.0.
First of all, I've already built this compiler on Debian GNU/Linux, so I was sure any problems will not be...
So, I read this GCC manual and I did all exactly as described:
cd gcc-4.7.0
./contrib/download_prerequisites
cd ..
mkdir gcc_build
cd gcc_build
/Users/dshevchenko/Downloads/gcc-4.7.0/configure --prefix=/Users/dshevchenko/Tools/GCC
make
So, MPC, MPFR and GMP was successfully downloaded, and ./configure was OK. But after few minutes after make I get this error:
checking for suffix of object files... configure: error:
in `/Users/dshevchenko/Downloads/gcc_build/x86_64-apple-darwin11.4.0/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
As I understand this can't be due error of dynamic linking with MPFR, MPC or GMP, because these libs was built inside of GCC source code tree.
In my ~/.bash_profile:
export DYLD_LIBRARY_PATH=/Users/dshevchenko/Tools/GCC/lib
Help me please, I'll be grateful for any advice.
Be sure you have the latest Xcode (4.4 at the time of this writing). There is a bug in the llvm compiler in some versions of Xcode (including 4.1, which I had). For Xcode 4.4, the command line tools must be downloaded from the Xcode preferences.
the follow solution helped me out:
$ export CC="gcc -D_FORTIFY_SOURCE=0”
$ $srcdir/configure ...
$ make
source: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342