Command I have used the following commands to build GCC 6.1:
sudo apt-get -y install libmpfr-dev libgmp3-dev libgmp-dev libmpc-dev flex bison libisl-dev
wget http://nl.mirror.babylon.network/gcc/releases/gcc-6.1.0/gcc-6.1.0.tar.bz2 -O - | tar xjvf -
cd gcc-6.1.0
./configure --enable-shared --disable-checking --enable-languages=c,c++ --disable-multilib
make -j4
When trying to compile GCC 6.1 on Ubuntu 16.04 / x86_64 I get the following error.
libtool: link: /home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc/xgcc -shared-libgcc -B/home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc -nostdinc++ -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib /usr/lib/x86_64-linux-gnu/crti.o /home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -lm -L/home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -lc -lgcc_s /home/user/build/gcc-6.1.0/host-x86_64-pc-linux-gnu/gcc/crtendS.o /usr/lib/x86_64-linux-gnu/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22
/usr/bin/ld: ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o): relocation R_X86_64_PC32 against symbol `_ZTCSt18basic_stringstreamIwSt11char_traitsIwESaIwEE16_St13basic_ostreamIwS1_E' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:606: recipe for target 'libstdc++.la' failed
make[6]: *** [libstdc++.la] Error 1
make[6]: Leaving directory '/home/user/build/gcc-6.1.0/x86_64-pc-linux-gnu/libstdc++-v3/src'
The problematic line seems to be this one:
/usr/bin/ld:
../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o):
relocation R_X86_64_PC32 against symbol
`_ZTCSt18basic_stringstreamIwSt11char_traitsIwESaIwEE16_St13basic_ostreamIwS1_E'
can not be used when making a shared object; recompile with -fPIC
It says recompile with -fPIC, but I can't seem to find the ./configure flag which makes sure libc++11convenience gets built with -fPIC.
I have been searching for a solution, but couldn't find anything. What should I do at this point to successfully compile gcc6.1?
Read carefully the GCC install instructions. GCC should not be built inside its source tree:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree.
You should try again, perhaps something like:
wget \
http://nl.mirror.babylon.network/gcc/releases/gcc-6.1.0/gcc-6.1.0.tar.bz2 -O - \
| tar xjvf -
mkdir Gcc6BuildTree
cd Gcc6BuildTree
../gcc-6.1.0/configure --enable-shared --disable-checking \
--enable-languages=c,c++ --disable-multilib --program-suffix=-6
make -j4
BTW, try first /usr/bin/gcc -v; that will give you how the system compiler was configured & built. And it is inspirational.
Also, I strongly recommend using --program-suffix= (and I would recommend configuring also the GCCJIT)
And you might try first to run aptitude build-dep gcc-6 (or gcc-5) to get the useful dependencies (dependencies for GCC 6 have much in common with dependencies for GCC 5).
Perhaps your Ubuntu already ships with some gcc-6? Did you try aptitude install gcc-6 ? See also this answer.
Also GCC 6.2 was released a few weeks ago (in august 2016). You'll better build gcc 6.2 instead of gcc 6.1
Notice also that the source tarball has a contrib/download_prerequisites script which you might find useful.
NB: gcc-help#gcc.gnu.org might be a better place to ask your question.
Related
When I tried to run example of gRPC for c++ in folder grpc/examples/cpp/helloworld it requires libraries which weren't compiled when I built gRPC with Cmake
Firstly I built gRPC in Ububtu 16.04 with instructions:
$ git clone -b $(curl -L https://grpc.io/release) https://github.com/grpc/grpc
$ cd grpc
$ git submodule update --init
$ cd third_party/protobuf
$ git submodule update --init --recursive
$ ./autogen.sh
$ ./configure --prefix=/usr
$ make
$ make check
$ sudo make install
$ sudo ldconfig # refresh shared library cache.
$ pkg-config --cflags protobuf # print compiler flags
$ pkg-config --libs protobuf # print linker flags
$ pkg-config --cflags --libs protobuf # print both
cd ../..
make
sudo make install
After that I tried to run example in folder grpc/examples/cpp/helloworld
grps/grpc/examples/cpp/helloworld$ make
i got several mistakes, which were resolved by copying grpc_cpp_plugin from folder grpc/bins/opt to /usr/local/bin and grpc++.pc and grpc++_unsecure.pc from grpc/libs/opt/pkgconfig/ to /usr/local/lib/pkgconfig.
When I tried for the next time command
grpc/examples/cpp/helloworld$ make
I've got message
g++ helloworld.pb.o helloworld.grpc.pb.o greeter_client.o -L/usr/local/lib `pkg-config --libs protobuf grpc++ grpc` -pthread -Wl,--no-as-needed -lgrpc++_reflection -Wl,--as-needed -ldl -o greeter_client
/usr/bin/ld: cannot find -lgrpc++
/usr/bin/ld: cannot find -lgrpc++_reflection
collect2: error: ld returned 1 exit status
Makefile:44: recipe for target 'greeter_client' failed
make: *** [greeter_client] Error 1
So, I searched these libs libgrpc++ in folder grpc/libs/opt, but there only these libraries
grpc/libs/opt$ ls --l
libaddress_sorting.a libgrpc_cronet.so.8
libaddress_sorting.so libgrpc_cronet.so.8.0.0
libaddress_sorting.so.8 libgrpc_plugin_support.a
libaddress_sorting.so.8.0.0 libgrpc.so
libares.a libgrpc.so.8
libboringssl.a libgrpc.so.8.0.0
libgpr.a libgrpc_unsecure.a
libgpr.so libgrpc_unsecure.so
libgpr.so.8 libgrpc_unsecure.so.8
libgpr.so.8.0.0 libgrpc_unsecure.so.8.0.0
libgrpc.a pkgconfig
libgrpc_cronet.a protobuf
libgrpc_cronet.so
So make didn't compile static and dynamic libraries for gRPC. Is it I did something wrong or didn't something or there is a bug? Version of protobuf is
:~$ protoc --version
libprotoc 3.8.0
:~$ which protoc
/usr/bin/protoc
Here is some output after I run "make" from root directory
[MAKE] Generating /home/user/cpp_test/grps/grpc/libs/opt/pkgconfig/grpc++.pc
[MAKE] Generating /home/user/cpp_test/grps/grpc/libs/opt/pkgconfig/grpc++_unsecure.pc
So it creates pkgconfig files for "libgrpc++*" libraries, but doesn't create these libraries.
And these having libgrpc++
libgrpc++ depbase=`echo google/protobuf/io/tokenizer.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
and
libgrpc++ depbase=`echo google/protobuf/util/delimited_message_util.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
only two lines
It looks like you only ran make from the third_party/protobuf directory (which you need to do as the first step), and ran make from the helloworld directory. If you did not do so already, you should run make from the grpc repository root directory, per the documentation. This will ensure the libgrpc++* C++ libraries are built.
So, I resolved this problem.
When I run "make" on root gRPC folder, compilation ended with such result:
[CXX] Compiling /home/user/cpp_test/grps/grpc/gens/src/proto/grpc/core/stats.pb.cc
/home/user/cpp_test/grps/grpc/gens/src/proto/grpc/core/stats.pb.cc:187:13: error: ‘dynamic_init_dummy_src_2fproto_2fgrpc_2fcore_2fstats_2eproto’ defined but not used [-Werror=unused-variable]
static bool dynamic_init_dummy_src_2fproto_2fgrpc_2fcore_2fstats_2eproto = []()
^
cc1plus: all warnings being treated as errors
Makefile:2924: recipe for target '/home/user/cpp_test/grps/grpc/objs/opt//home/user/cpp_test/august/grpc/gens/src/proto/grpc/core/stats.pb.o' failed
make: *** [/home/user/cpp_test/grps/grpc/objs/opt//home/user/cpp_test/august/grpc/gens/src/proto/grpc/core/stats.pb.o] Error 1
Because all warnings were treated as errors. And compiling of another libraries was stopped. So I manually added in Makefile in root gRPC directory flag -Wno-unused-variableat the end of 357 line. After adding this flag building of gRPC library went succesfully, and all libgrpc++* and libgrpc* libraries were built.
CPPFLAGS += -g -Wall -Wextra -Werror $(W_NO_UNKNOWN_WARNING_OPTION) -Wno-long-long -Wno-unused-parameter -Wno-deprecated-declarations -Wno-sign-conversion -Wno-shadow -Wno-conversion -Wno-implicit-fallthrough -Wno-sign-compare -Wno-missing-field-initializers -Wno-maybe-uninitialized -DPB_FIELD_32BIT -DOSATOMIC_USE_INLINED=1 -Ithird_party/nanopb -Ithird_party/upb -Isrc/core/ext/upb-generated -Wno-unused-variable
Passing --coverage to gcc while also linking LLVM causes an undefined reference to `__gcov_exit' error from the linker. I've set up a fresh project to try to isolate this problem. You can view the source on github and inspect the compiler output on Travis-CI.
This is the difference between a coverage and a non-coverage build
-DCMAKE_CXX_FLAGS="--coverage"
This is the difference between an LLVM and a non-LLVM build
target_link_libraries(Test
PUBLIC
LLVMCore
)
The LLVM job succeeds. The Coverage job succeeds. The LLVM + Coverage job fails with this error
undefined reference to `__gcov_exit'
Notes:
Check [CMake 3.13]: CMAKE_<LANG>_FLAGS for details regarding which env var affects which cmake var - as you figured out in your (deleted) answer
Only noticed cxx_std_17 from CMake 3.8, so you might want to update your cmake_minimum_required
Forked your repo to [GitHub]: CristiFati/gcov_error - An attempt to reproduce the gcov/llvm linker error and did some debugging on it
Beware, I might delete it someday
Was able to get my head around Travis CI, it's a real gold-mine
At the beginning I thought that it would be a trivial fix (something related to -fprofile-arcs, -ftest-coverage, -lgcov flags) as noted in [Man7]: GCC(1) (--coverage option), but it wasn't.
I wasn't able to reproduce the problem on my Ubuntu 16 pc064 VM (although Travis is very nice, it's kind of slow for debugging purposes (especially when due to rushing one might forget or add an extra character when editing :) ) and also it doesn't offer the same access level that a local machine does,) because the environment:
CMake 3.5.1
GCC 5.4.0
LLVM 3.8.0
is pretty far away from what's on the Travis Docker image. I must mention that neither I tried building the packages from sources (that would probably have caused lots of headaches), nor did I try downloading them from the repositories where they are downloaded during CI builds (didn't even check if those repos are public). Anyway the VM was pretty much unusable because:
I couldn't reproduce the issue (after some minor changes to adapt to older tools), everything worked
More: I ran into [SO]: Error when using CMake with LLVM (#CristiFati's answer)
It was eating me alive, so I ended up building 48 freaking times (on Travis) in order to get it working, and that is only because I failed to notice the obvious.
The problem
For each of the 3 configurations I'm going to paste the compile and link (G++) commands generated (from your build: [Travis CI]: Kerndog73/gcov_error - Build #24)
LLVM:
/usr/bin/g++-7 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/lib/llvm-7/include -std=gnu++1z -o CMakeFiles/Test.dir/main.cpp.o -c /home/travis/build/Kerndog73/gcov_error/main.cpp
/usr/bin/g++-7 -rdynamic CMakeFiles/Test.dir/main.cpp.o -o Test -L/usr/lib/gcc/x86_64-linux-gnu/4.8 /usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread -lm /usr/lib/llvm-7/lib/libLLVMDemangle.a
Coverage:
/usr/bin/g++-7 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/lib/llvm-7/include --coverage -std=gnu++1z -o CMakeFiles/Test.dir/main.cpp.o -c /home/travis/build/Kerndog73/gcov_error/main.cpp
/usr/bin/g++-7 --coverage -rdynamic CMakeFiles/Test.dir/main.cpp.o -o Test
LLVM + Coverage:
/usr/bin/g++-7 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/lib/llvm-7/include --coverage -std=gnu++1z -o CMakeFiles/Test.dir/main.cpp.o -c /home/travis/build/Kerndog73/gcov_error/main.cpp
/usr/bin/g++-7 --coverage -rdynamic CMakeFiles/Test.dir/main.cpp.o -o Test -L/usr/lib/gcc/x86_64-linux-gnu/4.8 /usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread -lm /usr/lib/llvm-7/lib/libLLVMDemangle.a
After lots of ghosts chasing, I noticed -L/usr/lib/gcc/x86_64-linux-gnu/4.8 being passed to the linker when LLVM is included. GCC 4.8 is installed on the Docker, so apparently GCC 7.4 was used for compilation, and GCC 4.8 for linking, which is Undefined Behavior.
I'm also pasting the Collect command (closer to the linker) from a slight variation (with -v) of #3. (all the libraries specified with -l* and without the full path (e.g. -lgcov, -lgcc_s, -lgcc) have the wrong version because will be picked up from the wrong directory):
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccyDh97q.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o Test /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. CMakeFiles/Test.dir/main.cpp.o /usr/lib/llvm-7/lib/libLLVMCore.a /usr/lib/llvm-7/lib/libLLVMBinaryFormat.a /usr/lib/llvm-7/lib/libLLVMSupport.a -lz -lrt -ldl -ltinfo -lpthread /usr/lib/llvm-7/lib/libLLVMDemangle.a -lstdc++ -lm -lgcov -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7/crtend.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.0
Some test commands placed in .travis.yml's after_script section, yielded the following output:
$ _GCOV_LIB7=/usr/lib/gcc/x86_64-linux-gnu/7/libgcov.a
$ (nm -S ${_GCOV_LIB7} 2>/dev/null | grep __gcov_exit) || echo ${_GCOV_LIB7}
0000000000001e40 000000000000008b T __gcov_exit
$ _GCOV_LIB48=/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcov.a
$ (nm -S ${_GCOV_LIB48} 2>/dev/null | grep __gcov_exit) || echo ${_GCOV_LIB48}
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcov.a
So, LibGCC (libgcov.a) was modified somewhere between the 2 involved versions (__gcov_exit symbol was added), and G++ knew it has one but Ld didn't provide it (because of the wrong lib) hence the error.
Now, why does LLVM add this library search path, I don't know (probably because it was built with GCC 4.8 - or smth close to it), but here's what I can think of:
LLVM is not meant to be used with GCC 7 (although I didn't find any such restriction while quickly browsing [LLVM]: Getting Started with the LLVM System)
A bug in LLVM (considering the other issue that I ran into, I tend to think this is the winner)
I found ways for both of them:
Use an older G++ (v4.8 - installed by default on the Docker)
export CXX=g++ (might even not be necessary)
G++ (not CMake this time) doesn't know about cxx_std_17, so the easiest way is to remove the afferent target_compile_features (the drawback is that code won't be C++17 "compliant")
Since I don't know how to "undo" passing the (faulty) library search path, the workaround that I came up with is to specify the correct one before it.
CMakeLists.txt:
cmake_minimum_required(VERSION 3.2)
project(gcov_test)
find_package(LLVM 7.0.0 REQUIRED CONFIG)
message(STATUS "Found LLVM: ${LLVM_DIR} ${LLVM_PACKAGE_VERSION}")
add_executable(Test
"main.cpp"
)
target_compile_features(Test
PUBLIC cxx_std_17
)
target_include_directories(Test
PUBLIC ${LLVM_INCLUDE_DIRS}
)
target_compile_definitions(Test
PUBLIC ${LLVM_DEFINITIONS}
)
if(LINK_WITH_LLVM)
# #TODO - cfati: Everything in this block is to avoid hardcoding default libgcc path (/usr/lib/gcc/x86_64-linux-gnu/7)
set(_COLLECT_LTO_WRAPPER_TEXT "COLLECT_LTO_WRAPPER=")
execute_process(
COMMAND bash -c "$0 -v 2>&1 | grep ${_COLLECT_LTO_WRAPPER_TEXT} | sed s/${_COLLECT_LTO_WRAPPER_TEXT}//" "${CMAKE_CXX_COMPILER}"
OUTPUT_VARIABLE _GAINARIE_COLLECT_TMP_VAR
)
get_filename_component(_GAINARIE_GCC_DEFAULT_PATH ${_GAINARIE_COLLECT_TMP_VAR} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L${_GAINARIE_GCC_DEFAULT_PATH}")
#set (GCCOPT "${GCCOPT} -L${_GAINARIE_GCC_DEFAULT_PATH}")
# #TODO END
target_link_libraries(Test
PUBLIC LLVMCore
)
endif()
Note: I tried to come up with something more elegant (I'm sure that it is), but I couldn't (tried using CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES, target_link_libraries, link_directories and a few more) at this point.
Today I wanted to recompile one of my projects. Compiling this project had already worked on my machine, but this time an error occured.
The compiler output goes:
fatal error: as: unknown host architecture (can't determine which assembler to run)`
for the line:
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I../../.vscode -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I../../.vscode -I. -o Main.o ../../Main.cpp
I tried to compile some other projects, but realized, that I wouldn't be able to compile anything using any c++ compiler, so I looked it up.
The only fitting thread I found was this one but the solution 'reinstalling binutils' didn't work for me (tried sudo apt-get install --reinstall binutils as well as --reinstall gcc, g++ and build-essential)
One possible reason for this problem that comes to my mind is the iOS-toolchain I installed yesterday - I had to install some different clang versions - but I actually didn't change anything on the system's assembler...
If someone's got an idea; any help would be appreciated :)
Additional info:
Ubuntu 16.04 LTS 64bit
AMD FX(tm)-6300 Six-Core Processor × 6
uname -m
returns x86_64
gcc -march=native -v -E - 2>&1 <<<'' | grep "cc1" | egrep -o -e $'-m(arch|tune)=[^ "\']+'
returns -march=bdver2 and -mtune=bdver2
already tried gcc [...] -march with bdver2 and other architectures
g++ -v -c HelloWorld.cpp gives me: http://pastebin.com/Ks2be0hL
type -a as says:
as is /usr/local/bin/as
as is /usr/bin/as
as --version sadly just show's me the error again, but info as tells me it's binutils-2.26.1-system from 2016-08-07
dpkg -S /usr/bin/as prints: binutils: /usr/bin/as
type -a as says as is /usr/local/bin/as. This is what gcc is running, not /usr/bin/as, because /usr/local/bin/as is found first in your $PATH search order. This is why re-installing packages and so on is having no effect: something else you installed (probably manually) installed a non-standard as.
Have a look at /usr/local/bin/as and figure out where it came from, and what to do with it. For now you can just rename it to as.unknown or something, and then everything will use the normal system assembler (/usr/bin/as).
Remove binutils and reinstall it using the following steps:
Create an installation directory /opt/cross, and make sure you have write permission to .
sudo mkdir -p /opt/cross
sudo chown user /opt/cross
export PATH=/opt/cross/bin:$PATH
Download and install
wget http://mirrors.muzzy.it/gnu/binutils/binutils-2.9.tar.gz
tar xvf binutils-2.9.tar.gz
cd binutils-2.9
linux32 ./configure --prefix=/opt/cross --target=aarch64-linux --disable-multilib
If dosn't work remove --target=aarch64-linux, the --disable-multilib option means that we only want our Binutils installation to work with programs and libraries using the aarch64 instruction set, and not any related instruction sets such as aarch32, run:
linux32 ./configure --prefix=/opt/cross --disable-multilib
linux32 make
linux32 make install
I was trying to compile an application for 32 bit target on x86_64 ubuntu 12.04 machine.
I installed the required packages using
sudo apt-get install gcc-multilib g++-multilib libc6-i386 libc6-dev-i386
The first command works generating the 32 bit version. However, the second command errors out
1. g++ -m32 hello.c
2. gcc -m32 hello.c
skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
Could anyone explain to me why gcc fails to work. Am I missing some libraries?
Thanks!
I upgraded my g++ to 4.8 and g++ -m32 stopped working too. Installing g++-4.8-multilib made -m32 option work with both gcc and g++.
I think you need this package of Ubuntu:
sudo apt-get install ia32-libs
Also confirm that you are using gcc multilib with gcc -v. If not set path accordingly or re-install gcc-multilib.
This is a very basic question, I only post because I've spent already some time into it. This is what I've done so far:
Downloaded and compiled the boost library:
sudo ./bootstrap.sh and sudo ./bjam install
This way it was installed into /usr/local/lib.
In my source code I've added only:
#include <boost/asio.hpp>
using boost::asio::ip::tcp
I compile it with:
g++ -I/usr/lib/jvm/java-6-openjdk/include -L/usr/local/lib -fPIC -lboost_system -shared -o libagent.so agent.cpp
However, ldd -d ./libagent.so gives me:
libboost_system.so.1.46.1 => not found
But there is no error thrown, when using the -lboost_system and ls /usr/local/lib gets me among other things:
libboost_system.so
libboost_system.a
What am I missing?
Did the ./bjam install tool also run the ldconfig(8) tool? ldconfig(8) needs to be run after new libraries are installed to update the caches used by ld.so(8) at program execution time.
You should compile it with:
g++ -I/usr/lib/jvm/java-6-openjdk/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib -fPIC -lboost_system -shared -o libagent.so agent.cpp
This makes it look for the boost library in /usr/local/lib at runtime, the -L option only makes it look in /usr/local/lib at compile time.