Gcc compilation "cannot compute suffix of object files: cannot compile" - linux

I'm actually reading the LFS book (version 7.1) and I'm blocked at page 53. Trying to compile gcc, I tried the following command:
./configure --target=$LFS_TGT --prefix=$LFS/build/gcc-build --disable-nls\
--disable-shared --disable-multilib --disable-decimal-float --disable-threads\
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath\
--disable-target-libiberty --disable-target-zlib\
--enable-languages=c\
--without-ppl --without-cloog\
--with-mpfr-include=$LFS/source/mpfr/src
--with-mpfr-lib=$LFS/source/mpfr/src/.libs\
--with-gmp-include=/mnt/LFS/source/gmp\
--with-gmp-lib=/mnt/LFS/source/gmp/.libs\
--with-mpc-include=/mnt/LFS/source/mpc/src\
--with-mpc-lib=/mnt/LFS/source/mpc/src/.libs
to run the configure script of gcc (of course I already compiled mpfr, mpc and gmp as well).
But once I launch:
make -j4
I get the following error:
checking for suffix of object files... configure: error: in `/mnt/LFS/source/gcc-4.6.2/x86_64-lfs-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
I tried to google for it and tried the solutions I found but nothing worked. Does anyone know why I get this error?

This issue is caused by dyanmic link library path issue when the test programs try to link against libmpc/libmpfr/libgmp.
Append below environment variable to allow ld link against the correct so file:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/mpc/lib/
Then try build gcc again.

"Building GCC is not trivial, but is not difficult if you follow the instructions carefully.
Many people rush into trying to build it without reading the installation docs properly and make one or more of these common mistakes:
do not run ./configure from gcc src dir (this is not supported) => you need to run configure from outside the gcc source directory
Note: if GCC links dynamically to the prerequisite libs (GMP/MPFR/MPC) then the shared libraries must be in the dynamic linker's path (LD_LIBRARY_PATH), both when building gcc and when using the installed compiler."
Simple example (without dynamic link to GMP/MPFR/MPC):
tar xzf gcc-4.8.0.tar.gz
cd gcc-4.8.0
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-4.8.0/configure --prefix=/opt/gcc-4.8.0
make
make install
Sources:
Advogato Doc -
GNU Doc

This error message can arise from a number of different reasons. The best way to figure out which one is to check the logfile '/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc/config.log' in the example below. Or in the original posters case '/mnt/LFS/source/gcc-4.6.2/x86_64-lfs-linux-gnu/libgcc' and look for the last error line.
Quoting GCC FAQ: http://gcc.gnu.org/wiki/FAQ#configure_suffix
Like any of the GNU projects, GCC is using the GNU autotools to
commonly configure the compilation for the specifics of the build
system. The configure script thereby uses small test programs -
usually called conftest.c - to test if certain functions and/or
features are available. If the compilation of such a test program
fails, you'll see an error message like:
checking for suffix of object files... configure: error: in
`/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc': configure: error:
cannot compute suffix of object files: cannot compile See `config.log'
for more details. make[2]: *** [configure-stage1-target-libgcc] Error
1 make[2]: Leaving directory `/home/manu/gcc/gcc'
This error message is quite misleading and frequently the problem has
nothing to do with the message. You have to check the file
'config.log' in the directory where the error occurred. In the example
above, you would have to check the 'config.log' file in the directory
'/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc'. There might be several
test programs that failed during the configuration, but some of these
failures are non-critical. Check for the last error entry in the file.
Common causes for this error message are:
Required libraries for the GCC build are missing, specifically MPFR,
GMP and MPC. If installed as shared libraries they must be in the
runtime linker's search path so they can be found. Please, follow the
instructions in the answer to Why does my ./configure and make fail?
The compiler crashed. For example, if there is an error such as
'conftest.c: internal compiler error:', this indicates a bug in the
compiler. If you are using an unmodified version of GCC, please follow
the procedure to report the bug.

This happens while creating a cross-compiler.
It's not referring to the top-level config.log, but $LFS_TGT/libgcc/config.log.
For me, in there, it says:
configure:3566: /foo/gcc/build/./gcc/xgcc -B/foo/gcc/build/./gcc/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/bin/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/lib/ -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/include -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/sys-include -o conftest -g -O2 conftest.c >&5
conftest.c:9:10: fatal error: stdio.h: No such file or directory
9 | #include <stdio.h>
| ^~~~~~~~~
compilation terminated.
configure:3569: $? = 1
configure:3782: checking for suffix of object files
configure:3804: /foo/gcc/build/./gcc/xgcc -B/foo/gcc/build/./gcc/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/bin/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/lib/ -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/include -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/sys-include -c -g -O2 conftest.c >&5
/foo/gcc/build/./gcc/as: line 106: exec: -E: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
configure:3808: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3822: error: in `/foo/gcc/build/aarch64-none-elf/libgcc':
configure:3824: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
Was your logfile similar?
It's my belief that the gcc compilation/installation process will take the various includes, run them through fixincludes to fix problems and tailor them to the target arch. The expected file is not present.
Referring to the Prerequisites page, I believe this section is relevant (emphasis mine):
C standard library and headers
In order to build GCC, the C standard library and headers must be present for all
target variants for which target libraries will be built (and not only the variant
of the host C++ compiler).
This affects the popular ‘x86_64-pc-linux-gnu’ platform (among other multilib
targets), for which 64-bit (‘x86_64’) and 32-bit (‘i386’) libc headers are usually
packaged separately. If you do a build of a native compiler on ‘x86_64-pc-linux-gnu’,
make sure you either have the 32-bit libc developer package properly installed (the
exact name of the package depends on your distro) or you must build GCC as a 64-bit
only compiler by configuring with the option --disable-multilib. Otherwise, you may
encounter an error such as ‘fatal error: gnu/stubs-32.h: No such file’
I believe that the solution is to obtain headers for the TARGET platform.

The problem is the assembler, "as" is missing. Build and install binutils for the target first.

In my case it was:
export LD_LIBRARY_PATH=/usr/mpc-082/lib:/usr/gmp501/lib:/usr/libelf0812/lib
Whereas each of the above library is the destination of what additional libraries you installed appended with /lib at the end.
Example: Lib-MPC:
1) Downloaded onto /usr/src/libmpc-src
2) cd into /usr/src/mpc-082
3) ../configure --prefix=/usr/mpc-082
4) make
5) make install
6) once installed, verify that you have the new libs installed under /usr/mpc-082-lib
7) add it to your LD_LIBRARY_PATH by doing:
export LD_LIBRARY_PATH=/usr/mpc-082/lib:$LD_LIBDADY_PATH
8) Repeat the same with your LibELF, and LibGMP
9) Go back and compile your GCC, should work after this.
Cheers
H

Related

Fail to build y86-64 simulator from sources

I am attempting to compile a simulator for Y86-64 code on Linux.I have already rewritten the makefile but it turned out like below.It said "undefined reference for 'matherr'".(Looks like it connects with gcc when linking)
(cd pipe; make all GUIMODE=-DHAS_GUI TKLIBS="-L/usr/lib/ -ltk8.5 -ltcl8.5" TKINC="-I/usr/include/tcl8.5 ")
make[1]: 进入目录“/home/gongchen/桌面/ICS/archlab-handout/sim/pipe”
# Building the pipe-std.hcl version of PIPE
../misc/hcl2c -n pipe-std.hcl < pipe-std.hcl > pipe-std.c
gcc -Wall -O2 -I/usr/include/tcl8.5 -I../misc -DHAS_GUI -o psim psim.c pipe-std.c \
../misc/isa.c -L/usr/lib/ -ltk8.5 -ltcl8.5 -lm
/tmp/cchKTZy7.o:(.data.rel+0x0):对‘matherr’未定义的引用
collect2: error: ld returned 1 exit status
Makefile:42: recipe for target 'psim' failed
make[1]: *** [psim] Error 1
make[1]: 离开目录“/home/gongchen/桌面/ICS/archlab-handout/sim/pipe”
Makefile:28: recipe for target 'all' failed
make: *** [all] Error 2
gcc -Wall -O2 -I/usr/include/tcl8.5 -I../misc -DHAS_GUI -o psim psim.c pipe-std.c \
../misc/isa.c -L/usr/lib/ -ltk8.5 -ltcl8.5 -lm
/tmp/cchKTZy7.o:(.data.rel+0x0):对‘matherr’未定义的引用
You are linking and getting an undefined reference error to matherr.
It looks like matherr is part of SVID math library. According to the matherr(3) man page the symbol is no longer present in Glibc 2.27 or above.
DESCRIPTION
Note: the mechanism described in this page is no longer supported by
glibc. Before glibc 2.27, it had been marked as obsolete. Since
glibc 2.27, the mechanism has been removed altogether. New
applications should use the techniques described in math_error(7) and
fenv(3). This page documents the matherr() mechanism as an aid for
maintaining and porting older applications.
The math_error(7) man page says that you should do the following to check for errors:
set errno to zero
call feclearexcept(FE_ALL_EXCEPT);
After the math calculation completes you should check the following for non-zero value to indicate error:
errno
fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW);
Since you are a guy or gal trying to use the program (and not a maintainer) I suggest two courses of actions. The strategy is to use a distro where things just work, and punt to the Y86 maintainer to fix it.
First, use a different, older distro that provides Glibc 2.26 or early. Something like Debian 8 (Glibc 2.19) or Fedora 25 (Glibc 2.24) should do just fine.
Second, file a bug report against Y86 project. The Y86 maintainers need to fix the problem, not students trying to learn the class material.
My classmates have a way to solve this problem: comment the code related to matherr, like the code in the picture. And the GUI mode works. 好厉害!

compiler (clang, android ndk r18) can't find stl_algobase.h

Trying to compile something since the update of the ndk to r18 gives me the following error:
make[1]: *** No rule to make target `/...../toolchains/arm/21/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/bits/stl_algobase.h', needed by `something.o'. Stop.
Looking manually for the folder "bits" showed that it is not there. So, of course, there is this error, because the compiler can't find 'stl_algobase.h'.
As far as I know now "gnustl, gabi++, and stlport have been removed." (https://github.com/android-ndk/ndk/wiki/Changelog-r18) So "The shared library version of libc++ will be used by default." (https://developer.android.com/ndk/guides/standalone_toolchain#c_stl_support)
I'm using the clang++ & clang compiler of the standalone toolchain and the following flags:
CXXFLAGS := -fPIE -fPIC
CXXFLAGS += -std=c++14
Note:
1) Using 'CXXFLAGS += -stdlib=libstdc++' it is the same.
2) I tried 'CXXFLAGS += -stdlib=libc++' too, but then the compiler will give this extra error: 'fatal error: 'vector' file not found'
My first thought is that the stl isn't linked properly, for some reason. Most likely there is some flag missing or the installation of the standalone toolchain was wrong. Here is how I did it:
sudo /...../Library/Android/sdk/ndk-bundle/build/tools/make_standalone_toolchain.py --api 21 --install-dir /...../Developer/toolchains/arm/21 --arch arm --force --verbose
If it is something that I was thinking of it could be, how to do it right? Or is it maybe something different that I did not think of? How to properly use libc++ in an external makefile with Android NDK?
You need to make clean or whatever your project's equivalent is. You have stale dependency files in your out directory.

How to install UHD device in redhawk using ubuntu 14.04

I'm using ubuntu 14.04 and i'm trying to install the UHD device from the github but i'm getting an error that won't allow it to build.
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
willie.thompson#seb215-wks07:~/redhawk/USRP_UHD/cpp$ make
CXX USRP_UHD-USRP_UHD.o
CXX USRP_UHD-USRP_UHD_base.o
CXX USRP_UHD-main.o
CXX USRP_UHD-template_impl.o
CXXLD USRP_UHD
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
seb215-wks07:~/redhawk/USRP_UHD/cpp$
Am I doing something wrong here or is the issue with Ubuntu?
For now, you can edit the Makefile.am file to fix this. At the end of the USRP_UHD_LDADD line, add -luuid, then you should be able to rebuild it successfully.
The version of g++ used in Ubuntu14 is stricter than the version used in CentOS6. Luckily, g++ is providing a good hint about what the issue is.
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
It is basically saying "What you want is here in libuuid.so.1 but you didn't put it on the command line so I'm refusing to use it". While in CentOS6 g++ is less strict and links regardless, assuming that is what you wanted.
You have two options, one is the easy way out that works quick, one is a better long term solution:
1) Run make again in verbose mode, this will show you exactly what calls are being made and you can fix the offending call. Lets do that below:
make V=1
< ... a bunch of calls to g++ that work fine or nothing if these have already run prior .... >
g++ -Wall -D__x86_64__ -D__linux__ -D__OSVERSION__=2 -DENABLE_EVENTS=1 -I/var/lib/redhawk/core/include -I/var/lib/redhawk/core/include/ossie -I/var/lib/redhawk/core/share/idl -pthread -I/usr/include -I/var/lib/redhawk/core/include/frontend -I/var/lib/redhawk/core/include/redhawk -I/var/lib/redhawk/core/include/bulkio -I/var/lib/redhawk/core/include/ossie -g -O2 -Wall -o USRP_UHD USRP_UHD-USRP_UHD.o USRP_UHD-USRP_UHD_base.o USRP_UHD-main.o USRP_UHD-template_impl.o -L/var/lib/redhawk/core/lib64 -lossiecf -lossieidl -lCOS4 -lomniDynamic4 -lomniORB4 -lomnithread -L/usr/lib/x86_64-linux-gnu -lboost_thread -lboost_regex -lboost_system -L/var/lib/redhawk/core/lib64 -lfrontend-2.2.0 -lfrontendInterfaces -lbulkio-1.10 -lbulkioInterfaces -luhd -llog4cxx
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
Okay, so now we have the long ugly g++ call, we simply need to add "-luuid" to the list of linked libraries so we can tack that on at the end and voila! It will return without error. Note that we simply hand ran 1 of the g++ calls so for good measure run Make again in case there are any additional build steps; in this case there are not, it will simply say "nothing to be done"
2) A better fix! So the build files clearly need some fixing.
If we take a look at the configure.ac we see that there are calls like this one:
PKG_CHECK_MODULES([LIBUHD], [uhd >= 3.5.3])
What this is doing is saying "Check pkg-config for the module uhd, ensure it is of version >= 3.5.3 and store any build related info in a variables prefixed with LIBUHD so that I can use it later". Sounds like what we want. We can check to see if pkg-config is aware of libuuid by viewing all of the packages it knows about:
pkg-config --list-all
That will show us everything pkg-config knows about and we see that it is aware of uuid. So, lets add a line to configure.ac right below the check for the UHD driver and see what affect that has. My line looks like this:
PKG_CHECK_MODULES([LIBUUID], [uuid])
I put no version constraint. Okay, so now in order for that change to be incorporated we need to rerun the reconf script and then we can see the configure output.
./reconf
./configure
<....a bunch of stuff....>
checking for LIBUUID... yes
<....a bunch more stuff....>
That's new! We are now checking for the uuid library in our configure call and if you take a look at the config.log file, new variables have been added:
LIBUUID_CFLAGS='-I/usr/include/uuid '
LIBUUID_LIBS='-luuid '
Alright, almost there! Take a look at the Makefile.am file. These variables are used there and dictate the calls to g++. Append our newly made LIBUUID_CFLAGS and LIBUUID_LIBS variables to the end of the USRP_UHD_LDADD and USRP_UHD_CXXFLAGS variables like I've done below.
USRP_UHD_LDADD = $(PROJECTDEPS_LIBS) $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB) $(BOOST_REGEX_LIB) $(BOOST_SYSTEM_LIB) $(INTERFACEDEPS_LIBS) $(redhawk_LDADD_auto) $(LIBUHD_LIBS) $(LIBUUID_LIBS)
USRP_UHD_CXXFLAGS = -Wall $(PROJECTDEPS_CFLAGS) $(BOOST_CPPFLAGS) $(INTERFACEDEPS_CFLAGS) $(redhawk_INCLUDES_auto) $(LIBUHD_FLAGS) $(LIBUUID_CFLAGS)
Since we've changed the Makefile.am files, we need to rerun ./configure. Rule of thumb is that ./reconf creates your configure script from the configure.* files and ./configure creates the Makefile's from your Makefile.* files so if you edit a downstream file you need to rerun the upstream script.
Alright, now that we've done that things should work! We've added a system check for libuuid via pkg-config using the configure.ac file, stored the outcome in a variable and used that in our makefile template.
None of this is really unique to redhawk so if you'd like more information there is loads of documentation on the autotools build system and pkg-config.

Building a toolchain with cmake to cross-compile for android

gcc (GCC) 4.8.1
android-ndk-r9
Hello,
My host machine is Fedora 19 and I want to create a tool-chain for compiling programs to run on android, later I want to extend this for iOS.
I get the following error:
Check for working C compiler: /opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -- broken
I am not sure why I am getting this error, as everything has been installed. I have also installed binutils-arm-linux-gnu. However, this is my first time do this type of thing, so many I have got something mixed up.
I am trying to create a toolchain file using cmake to croos-compile to run libraries on an android device.
I have installed the android-ndk-r9 in the following location with the path to the compiler:
/opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin
arm-linux-androideabi-addr2line
arm-linux-androideabi-ar
arm-linux-androideabi-as
arm-linux-androideabi-c++
arm-linux-androideabi-c++filt
arm-linux-androideabi-cpp
arm-linux-androideabi-elfedit
arm-linux-androideabi-g++
arm-linux-androideabi-gcc
arm-linux-androideabi-gcc-4.8
arm-linux-androideabi-gcc-ar
arm-linux-androideabi-gcc-nm
arm-linux-androideabi-gcc-ranlib
arm-linux-androideabi-gcov
arm-linux-androideabi-gdb
arm-linux-androideabi-gprof
arm-linux-androideabi-ld
arm-linux-androideabi-ld.bfd
arm-linux-androideabi-ld.gold
arm-linux-androideabi-ld.mcld
arm-linux-androideabi-nm
arm-linux-androideabi-objcopy
arm-linux-androideabi-objdump
arm-linux-androideabi-ranlib
arm-linux-androideabi-readelf
arm-linux-androideabi-run
arm-linux-androideabi-size
arm-linux-androideabi-strings
arm-linux-androideabi-strip
My cross-compile file is:
include(CMakeForceCompiler)
set(toolchain_path /opt/ndk/toolchains)
# Target system
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSTEM_VERSION 1)
# Compiler to build for the target
set(CMAKE_C_COMPILER /opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc)
set(CMAKE_FIND_ROOT_PATH /opt/ndk/toolchains)
I run this from my build/debug directory with my toolchain being in the root directory.
[ant#localhost debug]$ cmake -DCMAKE_TOOLCHAIN_FILE=arm-eabi-gcc.cmake ../..
Output
-- The C compiler identification is GNU 4.8.0
-- Check for working C compiler: /opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
-- Check for working C compiler: /opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -- broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler
"/opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/steve/mobile_progs/linux_pjsip/build/debug/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake "cmTryCompileExec379796592/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec379796592.dir/build.make
CMakeFiles/cmTryCompileExec379796592.dir/build
gmake[1]: Entering directory
`/home/steve/mobile_progs/linux_pjsip/build/debug/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/home/steve/mobile_progs/linux_pjsip/build/debug/CMakeFiles/CMakeTmp/CMakeFiles
1
Building C object
CMakeFiles/cmTryCompileExec379796592.dir/testCCompiler.c.o
/opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
-o CMakeFiles/cmTryCompileExec379796592.dir/testCCompiler.c.o -c
/home/steve/mobile_progs/linux_pjsip/build/debug/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTryCompileExec379796592
/usr/bin/cmake -E cmake_link_script
CMakeFiles/cmTryCompileExec379796592.dir/link.txt --verbose=1
/opt/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
CMakeFiles/cmTryCompileExec379796592.dir/testCCompiler.c.o -o
cmTryCompileExec379796592 -rdynamic
/opt/android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
error: cannot open crtbegin_dynamic.o: No such file or directory
/opt/android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
error: cannot open crtend_android.o: No such file or directory
/opt/android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
error: cannot find -lc
/opt/android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
error: cannot find -ldl
collect2: error: ld returned 1 exit status
gmake[1]: *** [cmTryCompileExec379796592] Error 1
gmake[1]: Leaving directory
`/home/steve/mobile_progs/linux_pjsip/build/debug/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec379796592/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:4 (project)
Many thanks in advance,
I managed to solve the problem by first going to this website:
http://developer.android.com/tools/sdk/ndk/index.html
There is an example of using the standalone toolchain that comes with NDK.
make-standalone-toolchain.sh --toolchain=arm-linux-androideabi-4.8
Extracted the into my /opt directory.
And using this sample toolchain cmake file
# Target system
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 1)
# Compiler to build for the target
set(CMAKE_C_COMPILER /opt/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gcc)
set(CMAKE_CXX_COMPILER /opt/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-g++)
Everything just worked after that. However, I couldn't get my previous problem working. Maybe I have set some environmental variables incorrectly to the wrong paths.
Hope this helps someone else.
Why you don't try this android-cmake. I still use this script and it works fairly well. If that approach does not fit your needs, you could use it as an inspiration anyway :-) .
For original problem from ant2009, please have a try to add following lines in .cmake:
SET (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=/opt/ndk/platforms/android-23/arch-arm" CACHE STRING "" FORCE)
SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --sysroot=/opt/ndk/platforms/android-23/arch-arm" CACHE STRING "" FORCE)
In 2020 the make-standalone-toolchain.sh approach is deprecated.
This is an updated CMakeList.txt:
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 24)
set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
PROJECT(mylib C)
CMAKE_MINIMUM_REQUIRED(VERSION 3.18.0)
SET( ${PROJECT_NAME}_CURRENT 1 )
SET( ${PROJECT_NAME}_REVISION 0 )
SET( ${PROJECT_NAME}_AGE 0 )
SET(VERSION "${${PROJECT_NAME}_CURRENT}.${${PROJECT_NAME}_REVISION}.${${PROJECT_NAME}_AGE}")
SET(SOURCES foobar.c)
ADD_LIBRARY(mylib SHARED ${SOURCES})
NOTE: For the ABI arm64-v8a CMake 3.18 is needed to detect the NDK toolchain correctly, 3.10 which is the version in Ubuntu 18.04, does not find the toolchain.

Setting up G++ or ICC for mpi.h on Ubuntu

I have never done any major programing outside of VS08.
I am trying to compile a program called LAMMPS with either of the two relevant make files. One calls g++ and the other calls icc (Intel's compiler).
icc produces this error:
icc -O -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -M write_restart.cpp > write_restart.d
write_restart.cpp(15): catastrophic error: cannot open source file "mpi.h"
#include "mpi.h"
and g++ throws this error
g++ -g -O -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -M verlet.cpp > verlet.d
pointers.h:25: fatal error: mpi.h: No such file or directory
compilation terminated.
The mpi.h file is located in /usr/lib/openmpi/include
It is my understanding that I need to set that $PATH variable which reads
bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/opt/intel/bin:/usr/lib/openmpi/include:
and $LD_LIBRARY_PATH which currently reads
/usr/lib/openmpi/lib:
SO, how does one include the mpi.h file? So that either icc or g++ find it?
mpi.h is a header for MPI library. That would be included if you use mpic++ MPI compiler wrapper instead of g++ in your makefile. mpic++ will call the appropriate compiler. From what you describe you have openmpi package installed on your ubuntu machine.
For more info, you need to consult the manual, e.g.
http://lammps.sandia.gov/doc/Section_start.html#2_2 (for LAMMPS)
and perhaps you need to see openmpi manual as to how to set up additional compiler. Not sure if this can be done after openmpi itself has been built. By default I think in Ubuntu openmpi compiler wrappers would only call g++. CMIIW.
Okay, so I got it to work with g++ when setting up cc as "mpic++.mpich2" instead of "mpic++"
you can try compile using openmpi make file in /src/MAKE
make openmpi
in my case, this option was successful

Resources