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.
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.
Hi,
I am struggling cross-compiling the Percy++ (percy.sourceforge.net/readme.php) for android phones that mainly require some other libraries to be included i.e. libgcrypt, socket++ etc. I can create the toolchain using android NDK with the following options 'android-17', 'ARM-based', 'linux-x86_64', and 'arm-linux-androideabi-4.8'. After I try to compile one of the required libraries, it gives me the following error:
arm-linux-androideabi-gcc --sysroot=/path-to-built-toolchain/sysroot
-I../include
-I. -march=armv7-a -c MakeDescAux.c
-I. -march=armv7-a -march=armv7-a -o MakeDesc MakeDesc.c MakeDescAux.o
-lm
./MakeDesc
./MakeDesc: 1: ./MakeDesc: Syntax error: word unexpected (expecting ")")
make[1]: *** [setup1] Error 2
make[1]: Leaving directory 'src'
> make: *** [all] Error 2
The reason that during the compilation, it creates some .exe files that are run during the compilation time on the desktop machine and they simply do not run, since these files have been compiled for another target i.e. android phone.
I want to create the .exe file out of the Percy installation. My question is; do I need some different linker or different linker settings, different LDFLAGS/CFLAGS/CPPFLAGS etc.? Is there any other way to compile the Percy without cross-compiling the required libraries? although I have tried with statically including the required libraries using the 'LOCAL_STATIC_LIBRARIES' option, but that also does not work. I think that the required libraries should be compiled before they are statically included to your main installation software. Any help in this regard is highly appreciated. Thanks.
Hi,
After researching why one binary is working in both systems (5.0 and 2.3.5) ive found that (is logic i know) static compiled binaries will be work in both versions.
The problem is that the binary will be increased in size a lot, but you don´t need to touch your application and just compile your c code and put in assets folder.
So all the static compiled binaries still will be working in both versions of Android
With the "file" command you can see if is statically compiled:
ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
This binary will work in any version of android and you have to compile with the static flag:
arm-linux-androideabi-gcc -static yourcode.c -o youbinary
I said the binary increase the size dramatically but for small binaries maybe its ok.
Regards,
Sylkat
So, I was able to compile and flash my Galaxy J5 from my Mac OSX Yosemite command line, and I'd like to share the experience. I'm a beginner at flashing and the Android world, so I struggled to understand I did not need Odin for taking control over my Galaxy J5.
The following should work for most versions of OSX / MacOS, as long as you have a compiler installed. But I've only tested it in my Yosemite machine.
All binary packages for Heimdall did not work for me. I was getting a persistent "libusb error -7 whilst sending packet". So I decided to build everything from source and forget about Odin, JOdin3 and the like.
I already had a development environment setup in my Mac, with the stock Xcode cc compiler. So I can only relate the additional dependencies I had to install (+ GIT). But it could be that I had additional software that is required from my brew installed packages. At the end of the post I list all my brew installed packages just in case.
1) Make sure you have a compiler (Xcode dev tools) installed. This is standard Apple stuff. Just google "install xcode mac" for your Mac version.
2) Install Homebrew (url is brew.sh), and the following packages:
Code:
brew install git
brew install cmake
3) Build libusb from source
Code:
cd /tmp
git clone https://github.com/libusb/libusb
cd libusb
./autogen.sh
make
cd /tmp
4) Build Heimdall
Code:
cd /tmp
git clone https://github.com/Benjamin-Dobell/Heimdall
cd Heimdall/
cmake -DLIBUSB_LIBRARY=/tmp/libusb/libusb -DLIBUSB_INCLUDE_DIR=/tmp/libusb/libusb -DDISABLE_FRONTEND=1 .
make
5) If you had no errors in the previous make steps, run Heimdall. You ca print your PIT, flash, etc, from the command line and never use Odin AFAIK. Take your phone into "Download Mode" (Vol Down + Home + Power button from a powered down state). Then try the print-pit Heimdall command (which takes a few minutes to complete).
Code:
cd /tmp/Heimdall/bin
sudo ./heimdall print-pit --no-reboot
sudo ./heimdall flash --17 recovery.img
etc....
BTW, move both Heimdall and libusb directories out of /tmp/ if you intend to preserve them after your Mac reboots. Create something like /Users/[your_user]/build/ to keep it safe and replave all "/tmp/" dirs in the lines above with your destination directory.
Have fun!
=====================
The following is a list of all my brew-installed packages, just in case you're missing a dependency and not sure which package I had that could make this work in my machine.
Code:
~/dev/build/Heimdall$ brew list
android-sdk gifsicle id3lib meld redis
atk git imagemagick net-snmp ruby
autoconf glew jbig2dec netcat scala
automake glib jpeg nettle sdl2
boost glm lame nexus sdl2_image
brew-cask gmp libepoxy nmap sqlite
cairo gnome-icon-theme libev node texi2html
cmake gnu-sed libffi openssl tig
cscope gnupg libogg p7zip tree
d-bus gnutls libpng pango unrar
ffmpeg go libtasn1 pcre v8
fontconfig gobject-introspection libtiff phantomjs watch
freetype gource libtool pixman webp
gawk gsettings-desktop-schemas libvo-aacenc pkg-config wget
gd gtk+3 libvorbis py2cairo x264
gdbm gtksourceview3 libvpx pygobject3 xvid
gdk-pixbuf harfbuzz libyaml python xz
geoip hicolor-icon-theme little-cms2 qemu yasm
gettext httrack macvim qt5
ghostscript icu4c maven readline