I got a cross compiled rootfs in ${ARMHOST} which I previously created via buildroot for a armv5te/ARM9 (ARM926t core also known as ARM926ej-s) target trying to use the CodeLite toolchain
waf distclean
ARMHOST="${HOME}/buildroot-2013.08/output/host";
export PKG_CONFIG_PATH="${ARMHOST}/usr/lib/pkgconffg/";
export CC="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/gcc";
export AR="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/ar";
export CROSS_COMPILE="/usr/bin/arm-none-eabi-";
export CFLAGS="-march=armv5te -I${ARMHOST}/usr/include/ -I${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/include/";
export LDFLAGS="-L${ARMHOST}/usr/lib/";
waf configure debug
Resulting in
'distclean' finished successfully (0.000s)
Setting top to : ~/Desktop/myapp
Setting out to : ~/Desktop/myapp/build
Checking for 'gcc' (c compiler) : not found
Checking for 'icc' (c compiler) : not found
could not configure a c compiler!
(complete log in ~/Desktop/myapp/build/config.log)
The wscript uses context.load('compiler_c gnu_dirs glib2') in each stage to load features.
Update #1 - if I replace compiler_c by gcc then I endup with:
CC="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gneabi/bin/gcc" AR="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/ar" ./waf configure
Setting top to : ~/myapp
Setting out to : ~/myapp/build
Checking for program gcc,cc : ${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/gcc
Could not determine the compiler type
So how can I tell waf that this compiler is gcc based? (code sourcery lite 2013 toolchain)
Do I have to create a new compiler profile or is there an easier way?
Do not use .../host/opt/ext-toolchain/arm-none-linux-gnueabi/bin/gcc but .../host/opt/ext-toolchain/bin/arm-none-linux-gnueabi-gcc - gcc detection is obviously done by some voodoo
Related
In order to make use of newer C++ 17 and 20 features, I want to switch from Apple clang to a homebrew installed vanilla clang. I installed it via brew install llvm.
When trying to build a minimal CMake based test project like
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=/usr/local/opt/llvm/bin/clang -DCMAKE_CXX_COMPILER=/usr/local/opt/llvm/bin/clang++ -G Ninja testProject
CMake fails with
-- The C compiler identification is Clang 13.0.0
-- The CXX compiler identification is Clang 13.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /usr/local/opt/llvm/bin/clang
-- Check for working C compiler: /usr/local/opt/llvm/bin/clang - broken
CMake Error at /Applications/CLion.app/Contents/bin/cmake/mac/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler
"/usr/local/opt/llvm/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/me/Projects/testProject/build/CLion/Debug/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/local/bin/ninja cmTC_d2d4b && [1/2] Building C object CMakeFiles/cmTC_d2d4b.dir/testCCompiler.c.o
[2/2] Linking C executable cmTC_d2d4b
FAILED: cmTC_d2d4b
: && /usr/local/opt/llvm/bin/clang -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_d2d4b.dir/testCCompiler.c.o -o cmTC_d2d4b && :
ld: library not found for -lSystem
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
So it seems that it fails to locate the correct library search path out of the box.
When trying to build a simple hello world program from the command line like
/usr/local/opt/llvm/bin/clang++ main.cpp -isysroot /Library/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk
It fails with even not finding some headers.
Supplying the header and library search path explicitly to the build command like
/usr/local/opt/llvm/bin/clang++ main.cpp -I"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include" -L"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
makes it work. However, both are no solutions to make the built-in CMake compiler check work and they don't seem like the correct way to go.
Once this is working correctly, I'm furthermore interested in being able to compile ObjectiveC++ code which currently fails with even more errors.
I think I understand the problem that the compiler does not know the correct search paths, but I'm lacking some understanding about how it would normally figure out those search paths in a CMake project.
I finally managed to get it working by supplying a few linker flags through the LDFLAGS environment variable:
-L/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib
In order to find the system libraries needed by the C compiler check
-L/usr/local/opt/llvm/lib
In order to find the C++ libraries as needed by the C++ compiler check
In order to successfully compile Objective-C code that links to Apple frameworks, I furthermore needed to add
-F/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks -lobjc
With those flags, I now can successfully build my projects. Still, I'm not 100% sure if this is the right way, especially if the libraries linked from /usr/local/opt/llvm/lib can be expected to be present on all target systems?
I am trying to build my own rootfile system for RPI using buildroot.
I am new to buildroot.
I have downloaded following cross compiler folder from git :--
https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian
as mentioned in this link :--
http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
How i will come to know what is the kernel header is used by above cross compiler ?
My installer GCC compiler is :--
arm-linux-gnueabihf-gcc
crosscompiler is downloaded from git at following location:--
~/home/gcc-linaro-arm-linux-gnueabihf-raspbian
Please suggest what value to fill here for toolchain selection :--
Toolchain type : External toolchain
Toolchain : Custom toolchain
Toolchain origin : Pre-installed toolchain
Toolchain path : ?
Toolchain prefix : ?
external Toolchain kernel header series : ?
external toolchain c library : ?
Mention the path of the cross compiler
Also mention the prefix. Since you are using arm-linux-gnueabihf-gcc your prefix is arm-linux-gnueabihf
external toolchain library : eglibc
I would like to set g++4.8 as the c++ compiler with qt creator.
I am in a OSX 10.8, QtCreator 2.8.0, and I have installed g++4.8 via homebrew.
I have setted the g++4.8 as the compiler: if I go in Projects > Manage Kits I have the GCC kit as default, and manually inserted a compiler called GCC 4.8, with compiler path /usr/local/Cellar/gcc48/4.8.1/bin/g++-4.8.
You can see it in the screenshots below. I also have /usr/local/Cellar/gcc48/4.8.1/bin in the Build Enviroment > PATH.
But, if I add QMAKE_CXXFLAGS = --version (I know it is dumb and it doesn't compile but it is just for testing) I receive in the "compiler window"
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1
(that is the same output i receive if I launch g++ from the shell) and not
g++-4.8 (GCC) 4.8.1
(that is what i receive if I launch /usr/local/Cellar/gcc48/4.8.1/bin/g++-4.8 from the shell) (and it is what I want too)
I remember that I had this problem in the past, I tried to resolved it hardlinking the g++4.8 to /usr/bin/g++ but it was not resolved (and just messed up everything).
What can I do?
I had the same problem and landed on your question...
Your question is how to make Qt Creator to use g++-4.8 for compilation.
The solution I devised is the following:
Solution
Add the following line somewhere in your project.pro file
QMAKE_CXX = g++-4.8
for instance just above the HEADERS list
Rationale:
The makefile synthesized by qmake uses the variable CXX to determine the C++ compiler.
You can set the value of the variable CXX at the level of the project configuration file by manually editing it.
Pros:
It solves your problem, you will compile your project using g++-4.8 without having to change the g++ compiler for the rest of your environment.
Cons:
You have to manually set that for each project.
Question for Qt developers:
is there a more natural way to set the g++ compiler at the Kit level? If there is not way, that might be a useful functionality to add.
I want to compile a source code, but there are some compiling errors about __sync_xxx functions (__sync_bool_compare_and_swap etc.)
GCC version on machine is 3.4.3 (it must be gcc 4.1 or over for supporting atomic builtins), so I have downloaded GCC v4.6, copied it to another directory (I didn't remove v3.4.3) then change the $PATH path for GCC but it doesn't work (the same error occurs).
I want to ask that is only changing gcc path with export PATH=... enough for compiling with new GCC?
Use the following configure option when compiling gcc:
--program-prefix=foo --program-suffix=bar
and it will produce bin programs of the form "foo-gcc-bar", so that you may differentiate different builds of gcc.
Replace foo and/or bar with an appropriate "tag" for your build (eg "-4.6" for example).
This way if it doesn't find your toolchain correctly it will fail fast rather than using the 3.4 version.
It also means that different toolchain builds can coexist in the standard installation prefix directories.
We have to use -march=686 switch to get it to work on intel.
Try checking and updating LD_LIBRARY_PATH, to use the lib path for the new gcc installed.
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package