I am using getline function and compiling using ndk but i am getting error :
'getline' was not declared in this scope
is this error due to limitations of armeabi-v7a or due to glib?How can it be resolved for the same function.
I have already #define _GNU_SOURCE before <stdio.h>
In general, when you encounter such an error, you go to your NDK directory and user either Midnight Commander (Linux) or Far Manager (Windows, Linux+Wine) to search the files (file mask: *.h) for your function, getline in this case. You will get a screenful of search results, and it's up to you to #include the right file.
Once in a while your function will not be found; in this case you search the 'net for a place where you can borrow the source.
Sometimes the function in the code being ported has just no meaning, e.g. if the function reads a line from stdin but the program going to invoke it is not a command-line utility, there is a problem.
Most likely, the source that you port #define-s switches for Linux, Mac (Darwin) and Windows, you have to choose the right configuration to derive the Android configuration from (and probably the Mac one will be the best).
Related
I'm trying to build libavformat with this MAKEFILE. Although the makefile includes avio.o file in its build instruction but it doesn't add any symbol for the functions that are declared on the header file url.h. Source folder which includes the avio.c, avio.h and url.h files can be found HERE.
The nm command for avio.o returns
nm: avio.o: File format not recognized
file command on avio.o shows the following output
avio.o: LLVM IR bitcode
I have checked the nm command on the generated libavformat.so and did not find any symbols for the functions declared on the url.h file
I have been stuck on this for two days. Could not figure out how to solve this problem!
Calling the ff_check_interrupt method and results in
undefined reference to 'ff_check_interrupt'
Configurations and flags.
FFmpeg Configuration File: Config.h
FFmpeg Root MakeFile: Root MakeFile
CC, CXX, CFLAGS, LDFLAGS: FLAGS
First off, a function declared by url.h should be defined in url.c, not in avio.c.
Second the only use of the ff_check_interrupt in avoi.c is within a static inline function, so indeed the toolchain is likely optimizing this symbol away.
I think what's occurring for you is that the toolchain making the decision that this is only used in this compilation unit.
Moving the definition of ff_check_interrupt to 'url.c' should resolve the issue. This is a library though, so out of your control.
However, this doesn't answer why thousands of users on Github have this same library in their code. I'd suggest comparing your Makefile against those (e.g. first search return is this one.
I am building a daemon on Android Platform. For which I have cross compiled the existing code, which is present in Linux to Android. Please consider my below 2 cases -
I cross compile the code using Cmake with Android NDK-15 and push manually to the board on which Android Code is available. The path in which we push is /system/lib. Then if I try to execute my daemon (which is also pushed manually to /system/bin ) everything works fine.
But,
2 The cross compiled library have been pushed into the AOSP code by writing an Android.mk file written in vendor specific folder. I have used BUILD_PREBUILTS method and was successfully able to push the libraries to /system/lib. Now, when I try to execute my application (Compiled with CMake ) I get a linker error.
Below is the error which I get ( Reference Example ) -
Below is the folder structure -
Total Number of folders - 3
a. abc folder which produces output libabc.so and links to libdef.so and
libghi.so
b. def folder which produces output libdef.so
c. ghi folder which produces output libghi.so
When I push all the 3 libraries (libabc.so, libdef.so, libghi.so ) directly in /system/lib and my executable (drive_test) which links all the 3 libraries, I have no issue. But, when I push it along with AOSP build I get the following error on execution of the executable (drive_test) -
a. Unable to link ../abc/def.so file.
I am unable to debug how to solve this linker issue. I am not getting whether it is because of CMake (or) any other issue.
If you're trying to make a system daemon (something that goes in /system/bin), don't use the NDK. Just use the AOSP build system.
In mydaemon/Android.bp (make sure to add this path to the root Android.bp file):
cc_library {
name: "libmylib",
srcs: ["mylib.cpp"],
}
cc_binary {
name: "mydaemon",
srcs: ["mydaemon.cpp"],
shared_libs: ["libmylib"],
}
The build system will deal with getting libraries and binaries into the right place for you.
I have a project that's fully functional in Xcode but not compiling in Eclipse ADT. I have successfully compiled and run android applications in the past, but this is my first time to create a custom class. To replicate the issue:
I create a new project, then add the following 2 files:
//Enemy.cpp
#include "Enemy.h"
USING_NS_CC;
bool Enemy::init()
{
if(!Layer::init())
return false;
return true;
}
//Enemy.h
#ifndef __ColorMirror__Enemy__
#define __ColorMirror__Enemy__
#include <iostream>
#include "cocos2d.h"
USING_NS_CC;
class Enemy : public cocos2d::Layer{
public:
CREATE_FUNC(Enemy);
virtual bool init();
};
#endif
I am able to see them in Eclipse in the list of classes.
Then I create a new enemy in HelloWorldScene.cpp as follows:
Enemy *newEnemy = Enemy::create();
This compiles and runs as expected in Xcode, but when I run build_native.py I get the following errors:
jni/../../Classes/Enemy.h:19: error: undefined reference to 'Enemy::init()'
jni/../../Classes/Enemy.h:19: error: undefined reference to 'vtable for Enemy'
Checking in the jni/../../Classes file, I am able to find Enemy.h and Enemy.cpp.
I have seen several explanations for fixes in other versions of Eclipse, and the suggestion it's a linker error, but I haven't figured out how to fix it in ADT.
Thanks!
So I'm not entirely sure which of these steps fixed the problem, and it may very well have been multiple issues, but here's what I did:
1) Added Enemy.cpp into Android.mk as follows:
Browse to game folder /proj.android/jni and open Android.mk
Open with TextEdit
Below the AppDelegate.cpp in LOCAL_SRC_FILES: added this:
../../Classes/Enemy.cpp \
Save
(still didn't work, so I took it out)
2) Changed workspace for Eclipse (which is specified on opening eclipse) and deleted old workspace
3) Downloaded and set up newest ADT package (Eclipse JUNO)
4) Upgraded Cocos2d-x from 3.1 to 3.2
(still didn't work)
5) Added Enemy.cpp to Android.mk again
Upon completing all those steps, everything works great and compiles as before.
Thanks to Wez Sie Tato for confirming that Enemy.cpp did in fact need to be added to Android.mk... Based on some comments I've seen elsewhere, it appears that my ADT package may have gotten damaged somehow, in conjunction with not having the proper line in Android.mk
I tried building i686-linux-android-gfortran using build-gcc.sh following this
(it's for androdindk-7b) but I get error about link.h. I added link.h from here, but it gives further more errors.
Has anyone tried enabling i686-linux-android-gfortran for x86 Android?
From https://groups.google.com/forum/#!msg/android-ndk/QR1qiN0jIpE/g0MHkhTd4YMJ as selalerer suggested. I didn't try this, so I'm posting as a community wiki for reference purposes.
Fortran for x86 Android
=================
The guide is based on this one, many thanks to Phil:
Compiling Android NDK with Objective-C-enabled gcc errors
1) Download and unpack Android NDK 'android-ndk-r8c', (the older -r8b NDK won't work due to missing link.h!):
wget http://dl.google.com/android/ndk/android-ndk-r8c-linux-x86.tar.bz2
2) Create somewhere a folder called 'toolchain-src' (e.g. inside the folder android-ndk-r8c),
'cd' to this new folder
3) Make sure to have git installed ('yum install git' or whatever..) and download
the toolchain sources:
git clone https://android.googlesource.com/toolchain/build.git
git clone https://android.googlesource.com/toolchain/gmp.git
git clone https://android.googlesource.com/toolchain/gdb.git
git clone https://android.googlesource.com/toolchain/mpc.git
git clone https://android.googlesource.com/toolchain/mpfr.git
git clone https://android.googlesource.com/toolchain/expat.git
4) Create the folder 'binutils', 'cd' to this directory, unpack
binutils-2.23 there:
wget ftp.gnu.org/gnu/binutils/binutils-2.23.tar.gz
tar -xvzf binutils-2.23.tar.gz
You should now have a folder toolchain-src/binutils/binutils-2.23
5) Change to folder toolchain-src/build, edit the Makefile.in, changing the line:
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
to
--with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran
6) In the file android-ndk-r8c/build/tools/build-mingw64-toolchain.sh change the line:
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++"
to
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++,fortran"
7) In the file android-ndk-r8c/build/tools/build-gcc.sh, change the line:
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-plugin"
to
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin"
8) In the file android-ndk-r8c/build/tools/build-host-gcc.sh, change the line:
ARGS=$ARGS" --enable-languages=c,c++"
to
ARGS=$ARGS" --enable-languages=c,c++,fortran"
And change the line
ARGS=$ARGS" --disable-libquadmath --disable-plugin --disable-libitm --disable-bootstrap"
to
ARGS=$ARGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin --disable-libitm --disable-bootstrap"
9) Build your new toolchain:
/your/path/to/android-ndk-r8c/build/tools/build-gcc.sh -j1 --gmp-version=5.0.5 --mpfr-version=2.4.2 --mpc-version=0.8.1 --binutils-version=2.23 --gdb-version=7.3.x /your/path/to/toolchain-src /your/path/to/android-ndk-r8c x86-4.7
(don't worry about messages like 'expr: warning: unportable BRE:')
10) And go down to your knees in front of the screen, praying to the Lord that somehow these
countless configure scripts doing checks that nobody needs, using an ugly shell language
that cooks your brain with indentation going from right to left, will somehow manage to
compile a zillion of far too small files (so that 10% of the time is spent on compilation
and 90% on starting up GCC), and after an hour of watching progress with
tail -F /tmp/ndk-YourUserName/build/toolchain/config.log
your toolchain will be magically ready. You'll find it in the android-ndk-r8c/toolchains folder.
11) Finally, 'cd' to the folder
'/your/path/to/android-ndk-r8c/toolchains/x86-4.7/prebuilt/linux-x86/i686-linux-android'
and run this command:
ln -s ../libexec libexec
Without this command, it may happen that g++ raises the error message
"g++: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found".
Using strace, I found that g++ looks in the wrong folder, but the link
above lets it find the file liblto_plugin.so nevertheless.
And here are a few lessons learned on the way, so that Google finds this page:
*) To speed up the compilation, you can remove the '-j1'. But only after you got
it to work once, since building in parallel on multiple CPU cores was reported to
cause additional troubles.
*) The error message "Link tests are not allowed after GCC_NO_EXECUTABLES" shows up
when linking fails for x86 (works for ARM). The reason is that GCC does not include
the proper ANDROID_STARTFILE_SPEC and ANDROID_ENDFILE_SPEC from
gcc-4.6.1/gcc/config/linux-android.h. GCC 4.6.1 only specifies them for ARM, but not
for i386, GCC 4.8.0 however does. The GCCs downloaded from Google also do,
so best use Google's GCC.
*) The error message "fatal error: link.h: No such file or directory" also happens
with Google's GCC, and apparently (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50877)
only when you enable additional languages like objc or fortran.
The bug thread is here: http://gcc.gnu.org/ml/gcc-bugs/2012-08/msg00494.html
MIPS has link.h in android-ndk-r8b/platforms/android-9/arch-mips/usr/include
In android-ndk-r8c, link.h is now also present in android-9/arch-x86/usr/include/link.h,
so this bug was fixed.
*) The error message "fatal error: quadmath_weak.h: No such file or directory":
It also happens with the latest gcc-4.8, so we can just continue using Googles GCC 4.7.
Google itself uses --disable-libquadmath, but we additionally need --disable-libquadmathsupport
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648). So this needs to be added in
android-ndk-r8c/build/tools/build-gcc.sh
and
android-ndk-r8c/build/tools/build-host-gcc.sh
*) The error message "error: Pthreads are required to build libatomic"
Happens when building the ARM version of gcc-4.8 downloaded from gnu.org,
better stay with Google's GCCs.
*) The GCC that came with android-ndk-r8c didn't work for me (error message about
libstdc++.so.6 being too old), while the one in android-ndk-r8b worked
without problems. Since the android-ndk should support as many environments
as possible, I'm not sure why the Googlers decided to depend on a newer libstdc++,
but the good news are that building your own toolchain solves the issue.
*) If you get an error while compiling generic-morestack.c, then replace
#ifdef linux
// On Linux, the first two real time signals are used by the NPTL
with
#if defined(GLIBC) && defined(linux)
// On Linux, the first two real time signals are used by the NPTL
I was wondering if there is any way to access the logcat logging data from native code ?
Also if someone knows what kind of shell can be accessed on the native linux system directly on the device itself (so NOT by starting a shell through adb on a client pc !!!) ?
Thanks in advance
You can either read the raw data fom /dev/log/main or you can run the built-in shell command logcat and pipe the result to a file descriptor as usual. The logcat command is usually preferably because then the printout is easier to filter and format.
As for the built-in shell, it is called toolbox and the source can be found in the Android open source project. The shell is rather similar to bash. Toolbox contains lots more functionality than just a shell. It is very similar to Busybox, but released under another license.
You can set it up using a log tag in your source file and then include the library as so:
#define LOG_TAG "some.unique.identifier" //I usually use the class name
#include <utils/Log.h>
Then in the Android.mk file you will need to add the liblog library dependency to your LOCAL_SHARED_LIBRARIES.
LOCAL_SHARED_LIBRARIES += liblog
Also, take note that logcat looks for the LOG_TAG definition to include as part of the tagging so it makes searching for your logs easier. Then you can log as such:
int my_int = 0;
ALOGI("some logs.... print my int: %d", my_int);
ALOGI is for info, you can also use ALOGE, ALOGD, ALOGV and ALOGW for error, debug, verbose and warning logging, respectively.
ALOG* is analogous to printf. I interchange them at times if I need to debug on different platforms, say Linux.