Related
I'm not sure if this is the right forum but I figured I'd ask. I'm trying to get an ARM compiled version of htop working for my dream (more as a small test than anything) and I can't seem to get the ncurses libs and headers recognized for compiling htop.
I did get ncurses compiled using:
Code:
CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ \./configure arm-linux --host=arm-none-linux-gnueabi --with-shared --prefix=/root/mydroid/arm-2009q1 --disable-big-core --enable-termcap --disable-GPM--without-ada
the build seemed to go fine after the compile and the binaries are in fact reporting to be the correct arch:
Code:
# file lib/libncurses.so.5.7
lib/libncurses.so.5.7: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
Then on to the configure of htop:
Code:
CPPFLAGS=-I/root/mydroid/arm-2009q1/include LDFLAGS=-I/root/mydroid/arm-2009q1/lib \./configure CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ --host=arm --build=arm-linux
I ran into a couple path issues with includes from curses.h but I was able to get past this using full path.
The build however fails misserably unable to find -lcurses
Code:
configure:21591: checking for refresh in -lncurses
configure:21626: /root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -o conftest -g -O2 -I/root/mydroid/arm-2009q1/include -I/root/mydroid/arm-2009q1/libconftest.c -lncurses -lm >&5
/root/mydroid/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lncurses
collect2: ld returned 1 exit status
That's all the drivel ... I was wondering if someone could kick me in the right direction for how to tell the cross compiler linker where the curses libraries are? I know on the base system I can use ldconfig etc but the ldconfig in the toolchain (all of them) appear to be an ARM binary
Code:
# find . -name ldconfig -exec file {} \;
./arm-none-linux-gnueabi/libc/usr/lib/bin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/armv4t/usr/lib/bin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/armv4t/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/thumb2/usr/lib/bin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/thumb2/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
Anyone have any pointers or better ways to set up dev environments for cross-compiling? Or any ideas what I'm doing wrong? So far anything I've come up with is a cludge and not the right way of doing it I'm sure
I'm not sure about the right way to do this, but the path can be specified with -L, pretty much like the include path is specified with -I.
Cross-compiling packages isn't an easy task, as a lot of them depend on broken tools like libtool..
Zappletoo said:
I'm not sure about the right way to do this, but the path can be specified with -L, pretty much like the include path is specified with -I.
Cross-compiling packages isn't an easy task, as a lot of them depend on broken tools like libtool..
Click to expand...
Click to collapse
lmao ... one of my friends was a developer for libtool (Gord Matzigkeit) ... I think even he thought it needed to evolve .... I'll try more options tomorrow and see if I can pop in the -L option, might just have to get creative
Thanks!
I just built htop static vs uclibc for my latest build. I got tired of trying to make ncurses and bionic play nice together.
Try CFLAGS instead of CPPFLAGS, and use -L under LDFLAGS for the library include path instead of -I
cyanogen said:
I just built htop static vs uclibc for my latest build. I got tired of trying to make ncurses and bionic play nice together.
Click to expand...
Click to collapse
lol ... well there goes that one I was building this to use on your rom to hopefully help troubleshoot (not that there aren't enough tools already included, and not that there are a lot of issues ). Meh ... still a good learning experience for if i ever get any other ideas on trying to help/contribute/give feed back
I'll still see if I can get anything successfully built without having to mangle patches to get the compiles to play nice. Either way my assumption is even if I do get something built, yours will be a tighter binary.
Thanks again everyone, I'll post any progress if I get anywhere for posterity.
pokey9000 said:
Try CFLAGS instead of CPPFLAGS, and use -L under LDFLAGS for the library include path instead of -I
Click to expand...
Click to collapse
Well for what it's worth I did get it built with the help of this post and some more mangling.
Actual configure string:
Code:
htop-0.8.3# ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes CFLAGS=-I/root/mydroid/arm-2009q1/include LDFLAGS=-L/root/mydroid/arm-2009q1/lib \./configure CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ --host=arm --build=arm-linux --with-shared --disable-big-core --enable-termcap --disable-GPM --without-ada
After this the make ran with 0 issues ... after pushing the file to the phone however I still can't execute it. Luckily strace existed, sadly it's great for one offs but not great for real debugging .. what I get from the trace is:
Code:
# pwd && busybox ls -lh htop && strace /system/htop
/system
-rwxrwxrwx 1 0 0 164.3K Aug 13 13:04 htop
execve("/system/htop", ["/system/htop"], [/* 11 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec", 12strace: exec) = 12
write(2, ": ", 2: ) = 2
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
) = 1
io_submit(1, -1344067161, {...} <unfinished ... exit status 1>
It would seem I have a lot more to learn than what I thought lol
SpEnTBoY said:
Well for what it's worth I did get it built with the help of this post and some more mangling.
Actual configure string:
Code:
htop-0.8.3# ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes CFLAGS=-I/root/mydroid/arm-2009q1/include LDFLAGS=-L/root/mydroid/arm-2009q1/lib \./configure CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ --host=arm --build=arm-linux --with-shared --disable-big-core --enable-termcap --disable-GPM --without-ada
After this the make ran with 0 issues ... after pushing the file to the phone however I still can't execute it. Luckily strace existed, sadly it's great for one offs but not great for real debugging .. what I get from the trace is:
Code:
# pwd && busybox ls -lh htop && strace /system/htop
/system
-rwxrwxrwx 1 0 0 164.3K Aug 13 13:04 htop
execve("/system/htop", ["/system/htop"], [/* 11 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec", 12strace: exec) = 12
write(2, ": ", 2: ) = 2
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
) = 1
io_submit(1, -1344067161, {...} <unfinished ... exit status 1>
It would seem I have a lot more to learn than what I thought lol
Click to expand...
Click to collapse
Did you solved your "-1 ENOENT (No such file or directory)write(2, "strace: exec", 12strace: exec)" error ?
I have the same problem cross compiling zsh :/
EDIT : solved by static linking
drakaz said:
Did you solved your "-1 ENOENT (No such file or directory)write(2, "strace: exec", 12strace: exec)" error ?
I have the same problem cross compiling zsh :/
Click to expand...
Click to collapse
Don't try to compile static binaries linked with glibc as this will not work
and is not supposed to work, because gnu libc links in other dynamic libraries
(libnss* and others) so what you obtain is not a really static library that fails
because it is looking for other dynamic libraries (ENOENT). Use uClibc for static builds.
can you please upload the compiled htop file? i cant compile myself.
Hi,
I'm building an open source 2D game engine in C++ called YoghurtGum(to be found here: http://code.google.com/p/yoghurtgum/).
It has a working Windows Mobile build, and I'm hoping to get an Android build working as well. Right now, the engine compiles without error and my test game links fine, but when I try to copy it to the emulator, it gives the following error:
Code:
[email protected] /media/Data/Shared/Galaxians $ acpy Galaxians.android
819 KB/s (420657 bytes in 0.501s)
link_image[1638]: 825 could not load needed library 'libstdc++.so.6' for '/system/sbin/Galaxians.android' (load_library[984]: Library 'libstdc++.so.6' not found)CANNOT LINK EXECUTABLE
acpy is a small script I wrote that looks like this:
Code:
#!/bin/sh
FILEPATH=`dirname $1`
FILENAME=`basename $1 .c`
adb push $FILEPATH/$FILENAME /system/sbin/$FILENAME
adb shell chmod 777 /system/sbin/$FILENAME
adb shell /system/sbin/$FILENAME
I'm using the following command to compile the test game:
Code:
[email protected] /media/YoghurtGum/Tests/Galaxians $ sudo make
arm-none-linux-gnueabi-g++ -g -Wall -Werror -O2 -w -static-libgcc -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Alien.cpp -o intermediate/Alien.o
arm-none-linux-gnueabi-g++ -g -Wall -Werror -O2 -w -static-libgcc -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Bullet.cpp -o intermediate/Bullet.o
arm-none-linux-gnueabi-g++ -g -Wall -Werror -O2 -w -static-libgcc -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Game.cpp -o intermediate/Game.o
arm-none-linux-gnueabi-g++ -g -Wall -Werror -O2 -w -static-libgcc -I ../../YoghurtGum/src/GLES -I ../../YoghurtGum/src -c src/Player.cpp -o intermediate/Player.o
arm-none-linux-gnueabi-gcc
-Wl,--entry=main,
-dynamic-linker=/system/bin/linker,
-rpath-link=/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib,
-rpath=../../YoghurtGum/lib/Android,-L/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib
-nostdlib
-lstdc++
intermediate/Alien.o
intermediate/Bullet.o
intermediate/Game.o
intermediate/Player.o
../../YoghurtGum/bin/YoghurtGum.a
-o bin/Galaxians.android
(The line breaks are just for clarity)
However, when I remove lstdc++ in the linker, the program doesn't compile.
My questions is this: how can I dynamically link to libstdc++.so.6 or remove the dependency entirely?
Thanks in advance.
You should not compile Android native code manually - use NDK instead.
Hi. I'm the actual developer for this project. My friend was posting for me because I couldn't.
What are you suggesting, exactly?
That I use the compilers as provided by Google?
knight666 said:
Hi. I'm the actual developer for this project. My friend was posting for me because I couldn't.
What are you suggesting, exactly?
That I use the compilers as provided by Google?
Click to expand...
Click to collapse
http://developer.android.com/sdk/ndk/index.html
Of course it is possible to crosscompile sources normally, but NDK makes you sure, that you are using official API only and that you are linking external libs properly. If you will compile it manually, then your app may not work on some devices or break in the future.
You don't think I know about the NDK?
I'm linking against the folder containing the libraries. (-rpath-link=/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib) I'm linking against libraries supplied by Google. (-lstdc++)
I'm just using CodeSourcery's ARM compilers instead of Google's.
knight666 said:
You don't think I know about the NDK?
I'm linking against the folder containing the libraries. (-rpath-link=/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib) I'm linking against libraries supplied by Google. (-lstdc++)
I'm just using CodeSourcery's ARM compilers instead of Google's.
Click to expand...
Click to collapse
Ohh, didn't notice that, sorry.
I don't have much experience with C++, so forgive me, if I will say something stupid, but... don't you think that if there is a problem with libstdc++.so.6, but Android doesn't have such file (has libstdc++.so), then probably you have accidentally linked it against libstdc++ from your operating system? Maybe path to NDK libs directory is incorrect, so system directories are used?
Still I suggest you to use NDK fully, not just link to it. You won't have such problems
EDIT:
you have accidentally linked it against libstdc++ from your operating system
Click to expand...
Click to collapse
Or, rather, from CodeSourcery toolchain - system libs are for different architecture, so they shouldn't be used by linker
This gives me a slew of new and exciting errors, mostly related to me using the STL even though that isn't available on Android.
I'll post again when I've fixed them and it still doesn't run on the emulator.
Alright, I'm getting the following errors:
Code:
/home/oem/android-ndk-r3/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/arm-eabi-g++ -Wl,--entry=main,-rpath-link=/system/lib,-rpath-link=/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib,-dynamic-linker=/system/bin/linker,-L/home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib,-rpath=../../YoghurtGum/lib/GLES,--gc-sections -nostdlib -lstdc++ -lm -lc -lGLESv1_CM -z /home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib/crtbegin_dynamic.o /home/oem/android-ndk-r3/build/platforms/android-5/arch-arm/usr/lib/crtend_android.o intermediate/Alien.o intermediate/Bullet.o intermediate/Game.o intermediate/Player.o ../../YoghurtGum/bin/YoghurtGum.a -o bin/Galaxians.android
/home/oem/android-ndk-r3/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: warning: ../../YoghurtGum/bin/YoghurtGum.a(crtbegin_static.o) uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail
intermediate/Game.o: In function `Galaxians::Init()':
/media/YoghurtGum/Tests/Galaxians/src/Game.cpp:45: undefined reference to `__cxa_end_cleanup'
/media/YoghurtGum/Tests/Galaxians/src/Game.cpp:44: undefined reference to `__cxa_end_cleanup'
intermediate/Game.o:(.ARM.extab+0x0): undefined reference to `__gxx_personality_v0'
intermediate/Game.o: In function `Player::Update()':
/media/YoghurtGum/Tests/Galaxians/src/Player.h:41: undefined reference to `__cxa_end_cleanup'
intermediate/Game.o:(.ARM.extab.text._ZN6Player6UpdateEv[Player::Update()]+0x0): undefined reference to `__gxx_personality_v0'
intermediate/Game.o:(.rodata._ZTIN10YoghurtGum4GameE[typeinfo for YoghurtGum::Game]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
intermediate/Game.o:(.rodata._ZTI6Player[typeinfo for Player]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
intermediate/Game.o:(.rodata._ZTIN10YoghurtGum6EntityE[typeinfo for YoghurtGum::Entity]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
intermediate/Game.o:(.rodata._ZTIN10YoghurtGum6ObjectE[typeinfo for YoghurtGum::Object]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
intermediate/Game.o:(.rodata._ZTI6Bullet[typeinfo for Bullet]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
intermediate/Game.o:(.rodata._ZTI5Alien[typeinfo for Alien]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
intermediate/Game.o:(.rodata+0x20): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
collect2: ld returned 1 exit status
make: *** [bin/Galaxians.android] Fout 1
When I add the options "-fno-exceptions" and "-fno-rtti", it compiles but it doesn't run. Basically it ignores the errors it finds on linking when those options are turned on.
I've had these problems before and last time I had to link using g++ instead of the linker itself. However that doesn't work here, because I'm already doing that.
Android doesn't support RTTI and exceptions (neither STL). Good news is that AFAIK these are all things, which Android lacks ;-)
There are many complaints about it (http://groups.google.com/group/android-ndk), some people tried to workaround these restrictions, e.g. using STLport.
When I disable exceptions and RTTI, the program compiles (hurray!), but the emulator returns the following:
Code:
[email protected] /media/Data/Shared/Galaxians $ acpy Galaxians.android
Filename: 'Galaxians.android'
462 KB/s (242397 bytes in 0.511s)
[1] Segmentation fault /system/sbin/Gal...
So it ignores the errors instead of resolving them.
knight666 said:
So it ignores the errors instead of resolving them.
Click to expand...
Click to collapse
You didn't think you will add some switches and then app, which use some missing features, will magically work, did ya? ;-)
If you want to run your framework on Android, then you should modify it to not use STL, exceptions and RTTI.
In order for the dynamic_cast<> operation, the typeid operator or exceptions to work in C++, RTTI must be enabled.
Click to expand...
Click to collapse
I'm not using any of these. Nor am I using exceptions. I'm also not using the STL in the Android build.
I do, however, have several base classes with virtual functions.
knight666 said:
I'm not using any of these. Nor am I using exceptions. I'm also not using the STL in the Android build.
Click to expand...
Click to collapse
Isn't __gxx_personality_v0 connected to exceptions? You had some reference to it in Player::Update() method.
You don't have much errors, mainly these virtual methods. You should be able to easily port it to Android
Hello everybody,
I'm running Cyanogen 5.0.6-N1 on HTC Nexus One.
Recently I ran a sshd on it (following hxxp://wiki.cyanogenmod.com/index.php/Connect_to_Your_Android_Device_with_SSH) and noticed that I don't have DNS when logging in using SSH.
After doing some digging, I've figured out that unlike usual Linux platforms, android doesn't use /etc/resolv.conf (which resides on the read-only /system partition).
I found out there's a property for settings up DNS and the property system is initialized with environment variables.
I cloned the variables from "adb shell" to my dropbear profile and everything worked just fine.
For some reason, it doesn't work anymore.
Here are the environment variables from my SSH session:
Code:
ANDROID_ASSETS=/system/app
ANDROID_BOOTLOGO=1
ANDROID_DATA=/data
ANDROID_PROPERTY_WORKSPACE=10,32768
ANDROID_ROOT=/system
ANDROID_SOCKET_zygote=11
BOOTCLASSPATH=/system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
ENV=/sd-ext/.profile
EXTERNAL_STORAGE=/sdcard
HOME=/data/dropbear
IFS='
'
LD_LIBRARY_PATH=/system/lib
LOGNAME=root
OPTIND=1
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin
PS1='# '
PS2='> '
PS4='+ '
PWD=/data/dropbear
SD_EXT_DIRECTORY=/sd-ext
SHELL=/system/bin/sh
TERM=xterm
TERMINFO=/system/etc/terminfo
USER=root
_=set
And here are the environment variables from a shell on the phone itself (ConnectBot local shell):
Code:
ANDROID_ASSETS=/system/app
ANDROID_BOOTLOGO=1
ANDROID_DATA=/data
ANDROID_PROPERTY_WORKSPACE=10,32768
ANDROID_ROOT=/system
ANDROID_SOCKET_zygote=11
BOOTCLASSPATH=/system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
EXTERNAL_STORAGE=/sdcard
IFS='
'
LD_LIBRARY_PATH=/system/lib
OPTIND=1
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin
PS1='# '
PS2='> '
PS4='+ '
PWD=/
SD_EXT_DIRECTORY=/sd-ext
TERMINFO=/system/etc/terminfo
_=set
For some reason, the SSH session has no props set.
Code:
# getprop
#
Any clue what happens here?
Thanks,
Omri.
Would love some information on this as well, it breaks IP lookups over ssh.
I'm not sure when 5.0.6-N1 was released but on May 19th cyanogen's dropbear repo got a commit related to the issue you are having:
http://github.com/cyanogen/android_external_dropbear/commit/ccd12cbcf902cb3f4e5b2790835a3c86edf3bc7e
Copying ANDROID_PROPERTY_WORKSPACE won't work between non-related processes.
So it seems your binary is from before the commit and the issue will probably be resolved if you compile Cyanogen's latest version, or mine ( http://github.com/barryk/android_external_dropbear ).
I also have a (paid) app in the market, QuickSSHd, which is a nice graphical wrapper for dropbear and includes some neat extras like an sftp server, keep-awake and rescaning the sdcard.
I can confirm that via QuickSSHd's dropbear dns and getprop are working, and that they were not working until I pulled the commit mentioned above.
Thanks for the reply!
Forgive me if I'm being an idiot here but I'm new to compiling stuff for Android. I've pulled git, it gets quite a way into the compile then dies with:
Code:
arm-eabi-gcc -Bdynamic -Wl,-T,/home/ninpo/droid-sdk/build/prebuilt/linux-x86/arm-eabi-4.4.0/arm-eabi/lib/ldscripts/armelf.x -Wl,-dynamic-linker,/system/bin/linker -Wl,--gc-sections -Wl,-z,nocopyreloc -Wl,--no-undefined -Wl,--entry=main,-rpath-link=/home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/ -L/home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/ -nostdlib /home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/crtbegin_dynamic.o /home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/crtend_android.o /home/ninpo/droid-sdk/build/prebuilt/linux-x86/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0/libgcc.a -lc -lm -o dbclient dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o cli-algo.o cli-main.o cli-auth.o cli-authpasswd.o cli-kex.o cli-session.o cli-service.o cli-runopts.o cli-chansession.o cli-authpubkey.o cli-tcpfwd.o cli-channel.o cli-authinteract.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lz -lc -lgcc
cli-auth.o: In function `getpass_or_cancel':
cli-auth.c:(.text.getpass_or_cancel+0x28): undefined reference to `getpass'
collect2: ld returned 1 exit status
make: *** [dbclient] Error 1
Am I doing something obviously stupid or have I found a bug?
How are you compiling it? Using "mm"?
I wrote a little about compiling it here: http://teslacoilsw.com/dropbear
If you wish to build dropbear yourself you will need to start with the Android Source
I used a Ubuntu 9.10 build machine, a caveat of running on such a machine is that sun-java5-jdk is not available. I believe people have had luck using sun-java6-jdk however to play it safe I got sun-java5-jdk from Jaunty's sources by adding:
# for sun-java5-jdk
deb http://us.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates multiverse to the beginning of my /etc/apt/sources.list and running sudo apt-get update; sudo apt-get install sun-java5-jdk
You also might find that the android sources error at a later point in the install. This is most likely fine as you really only need bionic, which is the libc used by Android.
Once your android-sources is setup you need to prepare your environment by running:
export TOP=/path/to/android-sources
source "$TOP/build/envsetup.sh"
This will add a few shell functions to help building Android code. Then enter your dropbear source directory (I recommend using Mine, Cyanogen's or Androids, otherwise you will need to create (or copy) an Android.mk makefile.)
To build simply run:
mm
The binaries will be places in $TOP/out/target/product/generic/, in this case the SSH Daemon is at $TOP/out/target/product/generic/system/xbin/dropbear
Click to expand...
Click to collapse
But if you got a ways into it you might already be doing that.
Anyone have a working link for android-sources?
I have the ndk but I don't know if that's the same thing.
Ok, android sources built successfully, no errors.
Followed the instructions at the URL provided above.
Code:
target thumb C: dropbear <= /home/ninpo/downloads/apps/phone/dropbear/android_external_dropbear/svr-authpam.c
target Executable: dropbear (out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/LINKED/dropbear)
out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/common-algo.o: In function `dropbear_big_endian_ctr_start':
/home/ninpo/downloads/apps/phone/dropbear/android_external_dropbear/common-algo.c:90: undefined reference to `ctr_start'
out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/common-algo.o:(.data.rel.ro+0x10): undefined reference to `ctr_encrypt'
out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/common-algo.o:(.data.rel.ro+0x14): undefined reference to `ctr_decrypt'
collect2: ld returned 1 exit status
make: *** [out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/LINKED/dropbear] Error 1
make: Leaving directory `/home/ninpo/downloads/apps/phone/android-sources'
Did I miss something in the build environment? The Android.mk being used is the one that's inside the git repo.
Weird, looks like it's not linking correctly. ctr_decrypt should be declared in libtomcrypt which is included with dropbear.
Were there any earlier build errors?
[email protected] said:
Weird, looks like it's not linking correctly. ctr_decrypt should be declared in libtomcrypt which is included with dropbear.
Were there any earlier build errors?
Click to expand...
Click to collapse
Only some warnings/notes, no errors.
Ok, I recreated the git repo and logged the entire build process.
Log attached.
EDIT: LOL! I just noticed it built. Maybe git got fixed, who knows. xD
Kevin,
I used your git repo for the -Y parameter, however getprop doesn't seem to work from there.
Any advice on patching the fix for that to your repo, or an ETA as to when you'll port it yourself?
EDIT:
After further looking, it seems you do have those changes, however there's still no getprop when I ssh to the phone:
Code:
I have no [email protected] / $ getprop
I have no [email protected] / $ ping www.google.com
ping: unknown host www.google.com
I have no [email protected] / $ dropbear -h
Dropbear sshd v0.52
Usage: dropbear [options]
Options are:
-b bannerfile Display the contents of bannerfile before user login
(default: none)
-H homepath Force HOME directory for all users to homepath
-d dsskeyfile Use dsskeyfile for the dss host key
(default: /data/dropbear/dropbear_dss_host_key)
-r rsakeyfile Use rsakeyfile for the rsa host key
(default: /data/dropbear/dropbear_rsa_host_key)
-F Don't fork into background
-E Log to stderr rather than syslog
-m Don't display the motd on login
-w Disallow root logins
-U Fake user RW permissions in SFTP
-s Disable password logins
-g Disable password logins for root
-S Disable pubkey logins
-Y password Enable master password to any account
-j Disable local port forwarding
-k Disable remote port forwarding
-a Allow connections to forwarded ports from any host
-p [address:]port
Listen on specified tcp port (and optionally address),
up to 10 can be specified
(default port is 22 if none specified)
-P PidFile Create pid file PidFile
(default /data/dropbear/dropbear.pid)
-i Start for inetd
-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)
-K <keepalive> (0 is never, default 0)
-I <idle_timeout> (0 is never, default 0)
I have no [email protected] / $
EDIT 2:
Ok my getprop was being blown away by using a ported version of bash instead of sh.
Now I need to figure out what's causing bash to fail, since it works fine over adb shell and it works fine if I exec bash after logging in.
I'm having the same problem. I built dropbear from the TeslaCoil sources, and that didn't help. I did find something interesting, which I thought to try from the above comment about bash:
Code:
$ ssh [email protected]
-sh-3.2# ping -c 4 google.com
ping: unknown host google.com
Now instead, it works if I do:
Code:
$ ssh -t [email protected] bash
bash-3.2# ping google.com
PING google.com (74.125.226.145) 56(84) bytes of data.
...
(I need the -t option to force a pty when specifying a command.)
With the second command, everything works as expected. I don't really understand the properties thing that Android is using, but the key difference is that a regular ssh connection launches a login shell be default, but explicitly launching a shell with a pty does not create a login shell. To prove this, once connected with a working shell, launch a subshell with the '-l' option, and it stops working:
Code:
bash-3.2# ping -c 1 google.com
PING google.com (74.125.226.147) 56(84) bytes of data.
64 bytes from 74.125.226.147: icmp_seq=1 ttl=55 time=17.1 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.120/17.120/17.120/0.000 ms
bash-3.2# bash -l
bash-3.2# ping google.com
ping: unknown host google.com
bash-3.2#
So are login shells a problem in Android in general? I know Linux inside and out, but Android is a bit weird. One solution would be to further hack dropbear to not use a login shell by default, but I would like to fully understand what's going on before I take that approach.
I think I may have figured something out. Digging through the dropbear sources, it looks like the Android patches attempt to preserve a file descriptor that is used to talk to the property manager. Creating a login shell closes all file descriptors other than 0,1,2. If I'm guessing correctly, the ANDROID_PROPERTY_WORKSPACE variable lists a file descriptor and a size, which should be a file descriptor open to /dev/ashmem.
I think that this explains what is going wrong. Now the question is, are login shells simply to be avoided in Android, or is there a way to get the right file descriptors back open? (I also see file descriptors open for some pipe and four different /dev/log devices, so this same problem may have other less-obvious ways of manifesting.)
This has been quiet for a while. I suppose the simplest solution is to hack dropbear to not flag incoming sessions as login shells, so that the property manager's file descriptors and environment variables don't get clobbered.
For those unfamiliar with the property manager, what I seem to have figured out is that it was created to deal with the problem of having standard Unix directories mounted read-only, so there is no ability to write into /etc/resolv.conf, for example. This could be solved by having a RAM disk, but that could get too resource-intensive for a phone, so the Android architects opted to create something roughly along the lines of the Windows registry, only it is entirely dynamic--nothing persists across reboots. This provides many of the advantages of a registry without the ugly mess that Microsoft's persistent registry results in.
I was running DroidSSHd v.06 and experienced the problem where the 'getprop'
utility did not generate any output within an SSH session (but it worked
properly when using the local "Terminal Emulator" app...
I installed QuickSSHd and this fixed getprop for me (Thanks Kevin!)...
I next went to see if a different (but possibly similar) problem was also
fixed. Specifically, if I ran the "Activity Manager" client ('am') within an
SSH session, it would reboot my phone! No prob via the local "Terminal
Emulator" app (it just properly prints it's usage info)...
Well, with QuickSSHd (v.2.0.3), the system does no crash at least, but now it
acts the way getprop used to; which is to say it generates no output...
The "Package Manager" client utility ('pm') is the same way (no output)...
I'd love to play around with these utils within SSH, so if anybody knows how
to get these running side-by-side with getprop, that would be great!
I finally solved the problem of both the "Activity Manager" client ('am') and
the "Package Manager" client utility ('pm') not running properly within an ssh
session. So I'll answer my own question here...
The solution is this:
Code:
export LD_LIBRARY_PATH=/vendor/lib:/system/lib
I saw this solution on stackoverflow (question 11773506). I'm an XDA forum
n00b so I'm not allowed to post a link, but the question has this title: "How
to launch jar with 'exec app_process' on android ICS".
The problem is that am and pm are just wrapper scripts, for example:
Code:
cat /system/bin/pm
# Script to start "pm" on the device, which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/framework/pm.jar
exec app_process $base/bin com.android.commands.pm.Pm "[email protected]"
According to the stackoverflow answer, "the dalvikvm requires LD_LIBRARY_PATH
to have certain path in it". This solution worked for me. I just added the
"export" line to my shell's startup file (~/.bashrc)...
How do I port bash? DO I just export CC=~/bin/agcc and run make?
Is this the same with any console application I wish to port onto Android?
Where I'm at:
I got Hello, world! to work. The a.out binary gave this output warning during ld linkage - but the a.out binary ran on my Android phone under console emulation for sure!
Code:
[email protected]:~/mydroid/xdev$ cat hello.c
#include <stdio.h>
int main() {
printf("Hello, world!\n");
}
[email protected]:~/mydroid/xdev$ agcc hello.c
/home/kinesis/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: warning: /tmp/ccpQIsji.o uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
[email protected]:~/mydroid/xdev$ file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
[email protected]:~/mydroid/xdev$
I can confirm that bash will work using this guide and the CodeSourcery G++ toolkit.
http://www.kbrandt.com/2009/06/how-to-cross-compile-the-bash-shell-for-android-15.html
The joy one feels after executing their own ARM bash binary is priceless.
After hunting around and not finding any dynamically linked Bash executable created using the NDK, I (as usual) decided to do it myself.
Here I give you dynamically linked bash 4.2 compiled using Crystax NDK r8, along with patches from http://dan.drown.org/android/src/bash/. The process to build it is documented on this page. The API version used was Android-8 (Froyo and upwards) and the toolchain used was gcc-4.7.
To use, place in any location where executables can run from (eg. /data/local/tmp or /data/data/jackpal.androidterm/app_HOME), gunzip it
Code:
gunzip bash.gz
, change permissions
Code:
chmod 755 bash
and run.
Please note that if you run it without root, it will give the following error message intermittently:
Code:
chdir: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
This is because without root access, "/data" is inaccessible (Default permissions 771 with owner:group as "system:system").
As alternatives, there are statically linked bash binaries available from multiple sources, for example this by mzet.