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.
Related
I followed the directions in the following URL to build a gcc compiler for Linux:
https://solarianprogrammer.com/2016/10/07/building-gcc-ubuntu-linux/
The resulting compiler builds 64-bit code with no problems.
However, when I try to build 32-bit code (by specifying the -m32 compiler option), I get errors.
Here are the errors that I get:
cannot find -lstdc++
cannot find -lgcc_s
skipping incompatible libgcc.a when searching foor -lgcc
cannot find -lgcc
Obviously, when I built the compiler, I did something wrong - can anyone tell me what I did wrong and how I can rebuild the compiler to build both 32-bit and 64-bit code.
You at least need to configure with --with-multilib-list=m32,m64 on the configure command line.1 You definitely need to not configure with --disable-multilib. You may also need to build&install additional versions of other libraries.
In general, searching the documentation for 'multilib' will show you all the places where it talks about building or using gcc with multiple target ABIs.
1This is the default on at least some versions of gcc. You could also add mx32 if you want to experiment with that.
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.
I am following this site to compile OpenCV for ARM.
It could not find my compiler so i hardcoded it into cmake file
find_program(CMAKE_C_COMPILER NAMES arm-linux-gnueabi-gcc-4.7)
find_program(CMAKE_CXX_COMPILER NAMES arm-linux-gnueabi-g++-4.7)
set(ARM_LINUX_SYSROOT /usr/arm-linux-gnueabi CACHE PATH "ARM cross compilation system root")
It compiles to aproximately 50% and then throws the following error:
Linking CXX shared library ../../lib/libopencv_viz.so
/usr/lib/libvtkCharts.so.5.8.0: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I am not every experienced in cross compilation (or straight compilation for the matter). How do i fix this?
I think it is a mismatch between libopencv_viz and libvtkCharts. Some of your 3rdparty libs are built for another platform. These libraries themselves must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which they are intended to be used.
Compiling OpenCV 2.4.10 worked for me. I did not have any preferred version. If you want to compile v3.0 see #Kornel's answer, that suggests to leave viz library out of compilation.
Use this command to checkout v2.4.10
git checkout 2.4.10
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
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install