I am trying to build a C project on Eclipse CDT with gcc.
First build worked fine, then I made a change to the source and second build appeared to try and link to a load of files I had not specified, then gets errors complaining it cannot find them. The gcc command it is running is:
gcc "-LC:\\SVN\\FloodAssessmentTool\\branches\\floatlite\\float\\python\\libs" -o float.exe "float\\python\\Lib\\site-packages\\markupsafe\\_speedups.o" "float\\.metadata\\.plugins\\org.eclipse.cdt.make.core\\specs.o" -lpython27
Whereas I am only expecting:
gcc "-LC:\\SVN\\FloodAssessmentTool\\branches\\floatlite\\float\\python\\libs" -o float.exe -lpython27
The only library I have specified to link against in the project settings is python27...
Whats happening?
Related
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.
*** Internal Builder is used for build ****
g++ -O0 -g3 -Wall -c -fmessage-length=0 -osrc\first.o ..\src\first.cpp
Internal Builder: Exec error:Launching failed
Build error occurred, build is stopped
Time consumed: 62 ms.
I am getting the above error in eclipse console when I tried to build my first "hello world" CPP program. Below are the steps I followed.
Installed Eclipse Europa.
Installed MinGW.
Open Eclipse goto window->preferences->c/C++->NEW CDT project wizard-> changed the Tool chain as "MinGW GCC".
When I opened the eclipse workspace manually there is no exe generated for the program.
My PATH variable in the project properties has "C:\MinGW" as value.
I searched much in net and still this "Launch Failed No Binaries" did not go off.
Please help...
"Launch failed No Binaries" means the program is not compiled.So this is the problem
related with MinGW GCC.Check you gave all the environmental variables necessary for the MINGW
correctly.
MoreOver I Suggest CodeBlocks IDE as a replacement.It is much Better than eclipse for c++
The link is CodeBlocks Download Link
I am using Eclipse 4.2 on Mac OS 10.8, with the command line tools (Xcode 4.6.3) installed. The clang compiler supports C++11 by means of using the following flags: -std=c++11 -stdlib=libc++.
I have an Autotools-managed project in Eclipse. Real compilation works as expected after overriding CXX and CXXFLAFGS environment variables when configure is called. However, the static code analysis in Eclipse continues to use GCC (the version installed with Xcode is GCC 4.2), so there is no support for C++11, and lots of lines display errors that are not real ones, making static code analysis almost useless.
Using homebrew I also installed GCC 4.7, but I have not succeeded to make Eclipse use that version (or clang++) for performing static code analysis.
Is it possible, when using an Autotools-managed project, to make Eclipse use a different compiler for the static code analysis? Where should I specify that?
After installing Xcode 5, and following the directions in this question, I managed to solve the problem (I cannot test anymore whether this applies to Xcode 4.6 too).
The solution is to go to Project properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers -> CDT GCC Built-in Compiler Settings, and in Command to get compiler specs: append -std=c++11 -stdlib=libc++.
After doing that change, the line should look like:
${COMMAND} -E -P -v -dD ${INPUTS} -std=c++11 -stdlib=libc++
I have a Beaglebone (Rev: A6) and i want to develop C/C++ program in windows 7 using Eclipse and then transfer executable in the board. But i'm having trouble setting up compiler/debugger/toolchain needed for Beaglebone. Searching the internet only gives me how to setup environment in Linux like installing 'arm-linux-gnueabi', setting up the paths to 'includes' etc. I need a step by step instruction to set up the environment in Eclipse in a windows machine. Can anyone help ?
I have tried these steps:
1. I have GNUARM installed on windows.
2. On eclipse IDE i open a C++ project with Corss GCC.
3. From project -> properties -> C/C++ build -> settings i add 'arm-elf-' to every cross compiler command.
4. From the GNUARM installation directory i add few path to '.../include/' in the 'C++ General -> paths and symbos'.
my 'build all' shows something as below:
10:32:20 **** Build of configuration Debug for project h ****
make all
Building file: ../src/hello.cpp
Invoking: Cross G++ Compiler
arm-elf-g++ -I"C:\GNUARM\include\c++\4.1.1" -I"C:\GNUARM\include\c++\4.1.1\arm-elf" - I"C:\GNUARM\include\c++\4.1.1\backward" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP - MF"src/hello.d" -MT"src/hello.d" -o "src/hello.o" "../src/hello.cpp"
Finished building: ../src/hello.cpp
Building target: h
Invoking: Cross G++ Linker
arm-elf-g++ -L"C:\GNUARM\lib\gcc\arm-elf\4.1.1\include" -o "h" ./src/hello.o
Finished building target: h
10:32:23 Build Finished (took 2s.967ms)
It is simple 'Hello world' printing program. From the project explorer 'Debug->src->hello.o -[arm/le]' i copy it and when run on beaglebone with
chmod ugo+x hello.o
./hello.o
-sh: ./hello.o: cannot execute binary file
the above massage is printed. I don't know what i did wrong. Perhaps the ARM environment in eclipse is set up incorrectly.
Isn't hello.o the pre-linked object file (just the compiled content of hello.cpp)? It doesn't contain the startup code or any library functions. The linker adds those to produce the final output.
Don't you want to run the linker ouput file h (which should already be executable)?
i got my answer here. http://www.acmesystems.it/foxg20_eclipse_windows_c. CodeSourcery was the toolchain that i was looking for and this also explains how to setup the corss compiling environment.
I am trying to debug clang using eclipse. I have put a break point in clang/lib/lex/preprocessor.cpp at the preprocessor's constructor.
I have set a "test.c" file as an argument in the debug configurations.
Went to Run-> Debug As-> Local C/C++ Application.
It asked "Choose local application to debug". I chose "clang" and clicked OK.
It started building the code. build completed.
Stopped at main() in the debug window. (No source available for main())
After some step overs, it says "terminated: gdb Debugger (Exited. Exit code=255)"
I am not taken to the clang code (preprocessor code). can someone please tell me how to debug the clang code.? I want to see the code flow in clang. and how clang is constructing the AST.
Clang binary in fact contains two apps: driver and compiler frontend itself. The latter is executed via -cc1 cmdline option. So, just add -v to clang command line to see the actual sequence of tool invocation, grab the frontend cmdline (the one containing -cc1) and use this cmdline for debugging.
Had the same problem - you are missing the -g flag (enable debug info) when you are building your binaries.
When running the cmake run it with the CMAKE_BUILD_TYPE option:
cmake -G "Eclipse <CDT_Version> - Unix Makefiles" -D_ECLIPSE_VERSION=<eclipse_version> -DCMAKE_BUILD_TYPE=Debug <llvm_source_path>
example :
cmake -G "Eclipse CDT4 - Unix Makefiles" -D_ECLIPSE_VERSION=4.4 -DCMAKE_BUILD_TYPE=Debug ../llvm/
hope that this helps.