Closed kollaesch closed 6 years ago
I will work on this this evening as soon as someone upload the SDK to other cloud service
I tinkered for some time to setup the cross-build-env. First one didn't work. I'm playing with crosstool-NG right now.
Mmm.. the crosscompiler is usully call toolchain and it is part of the SDK. You don't need to use other compiler like NG.
Let me know if you cannot make it work....
I uploaded a copy of SDK to GDrive. https://drive.google.com/file/d/0B40VEajjRUcHTmNuN2N0R3dWaUk/view?usp=sharing
@mwenyuan thanks. I downloaded it. @willthrom I will also switch to the provided toolchain. But first I have to get familiar with it.
I compiled a test Program but still trying to make it work in the Camera. After that I will compile a SSH daemon.
@willthrom How did you set it up? (according to "GM8136_Linux_User_Guide_V1.0.pdf" / page 13 ?) I'm too tired ...
@kollaesch after 8 hours in front of a computer at work... + another 3 reading logs/firmwares and scripts. I can say I am tired.
Yes Page 13, take a look to the example sw_dbg.
By the way, I compiled my first TestProgram for this camera and it works, but if I tell you straight away.. I will deprive you from all the fun :)
@willthrom to kind of you ;) I ruined my Archlinux somehow with the toolchain yesterday. Apparently the upgraded packages were compile with the cross compiler. I have to fix that first.
@kollaesch Did you export the compiler?? hahahaha (sorry :P)
I have the dropbeer compiled and running, but some problems logging in.
Done. I will upload a release soon
I didn't get the compiler running. (./arm-unknown-linux-uclibcgnueabi-gcc -v
)
Brought me 'file not found'
. Same with the absolute path.
Ideas? (costed me some sleep :/ )
@kollaesch
1) In what platform are you trying to compile? 2) Did you untar the toolchain in Linux? 3) did you check the permission of all the files? 4) Did you add the PATH of the /usr/src/linuxarm.../toolchain.../../bin to your environment path?
[x] 1,2) 'Archlinux x86_64', yes
[x] 3) yes - looked good.
# ls -l
total 7924
-rwxr-xr-x 2 root root 620602 31. Dez 2013 ar
-rwxr-xr-x 2 root root 1097201 31. Dez 2013 as
-rwxr-xr-x 2 root root 217004 31. Dez 2013 c++
lrwxrwxrwx 1 root root 3 31. Dez 2013 cc -> gcc
-rwxr-xr-x 2 root root 217004 31. Dez 2013 g++
-rwxr-xr-x 1 root root 185792 15. Sep 13:54 gcc
-rwxr-xr-x 4 root root 1047333 31. Dez 2013 ld
-rwxr-xr-x 4 root root 1047333 31. Dez 2013 ld.bfd
-rwxr-xr-x 2 root root 603682 31. Dez 2013 nm
-rwxr-xr-x 2 root root 761721 31. Dez 2013 objcopy
-rwxr-xr-x 2 root root 919637 31. Dez 2013 objdump
-rwxr-xr-x 2 root root 620601 31. Dez 2013 ranlib
-rwxr-xr-x 2 root root 761720 31. Dez 2013 strip
[x] 4) yes (export PATH=$PATH:/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin
)
# strace ./gcc
execve("./gcc", ["./gcc"], 0x7fffe22d4990 /* 18 vars */) = -1 ENOENT (No such file or directory)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
getpid() = 387
exit_group(1) = ?
Same result when called with absolute path. Strange.
What's up with the makedev
??
@kollaesch First... the toolchain is 32 bits, so you might have to install the 32 bit compatible package. Then, my /usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin look quite different... did you change the name of the binaries?
usually it is better to keep the original ones so the system doesn't get confuse (I guess that is why you broke your system before).
By the way.. usually the PATH is defined the other way around because if you have another folder in the PATH with gcc/cc will use those.
From export PATH=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin To export PATH=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin:$PATH
@willthrom Thanks! first: /usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin the arm-part was important.
In the meantime I installed it on a second pc. Same error first. Then with arm-linux it works there.
And no, I didn't change anything. I extracted the tars. The documentation is partially wrong there.
(page 13) First they mention uclibc_gnueabi-4.4.0_ARMv5TE.tgz
then add the path the environment toolchain_gnueabi-4.4.0_ARMv5TE
.
Since I couldn't find uclibbc*tgz
I took toolchain*tgz
.
Did I something wrong there?
Hi, maybe you can create a docker image once it works and you know how :)
@kollaesch toolchain* is fine.. you need to extract it under /usr/src/arm-linux (the same folder as the documentation states).
In any case, you said it is working now.... so good, right?
@snoerenberg we definitely could create a docker image to compile packages, not more VM, but I guess it is a low priority of this project.
@willthrom
Unfortunately it's not working: even with your export PATH=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin:$PATH
it still grabs the gcc of the system (7.2.0)
... driving me nuts. Isn't that complicated ...
cd /usr/src
tar zxf arm-linux-3.3_2015-01-09.tgz
cd /usr/src/arm-linux-3.3
tar xfz ../toolchain_gnueabi-4.4.0_ARMv5TE.tgz
export PATH=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin:$PATH
both bring file or directory not found
/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc -v
/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin/gcc -v
I agree, having a docker-image would definitely be a good thing for future purposes.
My toolchain folder looks very different to the one you have. I cannot posted because I am at work.
the file name are much longer (like arm-linux-unknown-aclliasdasd-gcc)
just run in that folder "file gcc" and see what it returns... but I would say you don't have the same toolchain I used to compile the SSH Server and busybox.
This is my suspicion also. I downloaded the SDK from Googledrive (mwenyuan).
host1 in /usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin
)
# file gcc
gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=8173314ec1d26cd5ffcd72
5af2a57de7ee964434, stripped
host2 in /usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin
)
# file gcc
gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=8173314ec1d26cd5ffcd72
5af2a57de7ee964434, not stripped
looks good. What's your BuildID[sha1]
??
I cannot check it now but.. that seems to be a valid 32 bit file. If you Unix System support 32-Bit Intel platform binaries so you should be able to run it.
I would check permission of the file and run it as ./gcc
Again, I was your before your unix is 64Bits... you might need to check in that Linux Distribution if the 32Bit libraries are installed:
dynamically linked, interpreter /lib/ld-linux.so.2 You need to have a 32Bit version of this library...
@willthrom :+1: thanks, that helps --> Arch Linux phases out 32-bit support So if so, would either have to build a docker, or setup a different linux-distribution.
I installed lubuntu through Virtual Box but I wasted as much time as I could do starting a docker with alpine distribution and installing the make and other package to compile... If I am bored enough I would try but not this weekend.
My plan was also to use an alpine-docker-image.
(docker pull multiarch/alpine:x86-edge
for 32bit-support)
Same here, no time during the weekend.
Update, I guess my toolchain-download is still messed up. I just built a docker-container, but the issue remains.
Please check the Dockerfile.txt (without the
.txt
) Thanks!!@willthrom which toolchain did you download?
I switched to a debian-image. The working Dockerfile is here.
running gcc -v
returns ...
root@1099211cbd08:/usr/src# gcc -v
Using built-in specs.
Target: arm-unknown-linux-uclibcgnueabi
Configured with: /usr/src/arm-linux-3.3/buildroot-2012.02/output/toolchain/gcc-4.4.0/configure --prefix=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr --build=i
686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-unknown-linux-uclibcgnueabi --enable-languages=c,c++ --with-sysroot=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_AR
Mv5TE/usr/arm-unknown-linux-uclibcgnueabi/sysroot --with-build-time-tools=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-unknown-linux-uclibcgnueabi/bin --d
isable-__cxa_atexit --enable-target-optspace --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/usr/src/arm-linux-
3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr --with-mpfr=/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr --enable-threads --disable-decimal-float --with-float=soft --
with-abi=aapcs-linux --with-arch=armv5te --with-tune=arm926ej-s --with-pkgversion='Buildroot 2012.02' --with-bugurl=http://bugs.buildroot.net/
Thread model: posix
gcc version 4.4.0 20100318 (experimental) (Buildroot 2012.02)
@kollaesch thats looks much better
The unfortunate thing ...
# ./configure
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/dropbear-2017.75':
configure: error: C compiler cannot create executables
See `config.log' for more details
configure.log brings:
configure:2672: gcc conftest.c >&5
gcc: error trying to exec 'cc1': execvp: No such file or directory
Check your PATH environment variable. I don´t think ./configure is using the proper compiler.
(by the way, just start with a basic program, like a hello world, with a simple make file....)
The PATH is set in the Dockerfile itself
PATH="/usr/src/arm-linux-3.3/toolchain_gnueabi-4.4.0_ARMv5TE/usr/arm-linux/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
I also can't find the so called 'cc1'. Can also be that this is a version-problem. (That dropbear needs a newer gcc?)
I closed this issue because I already compile dropbear using the toolchain from the SDK, the toolchain contain all the binaries (gcc) you need, so you cannot "get" a new version of gcc.
According to your configure log, it seems you are not using the compiler from the SDK.
You should start with something easier, like this example I created..... test.zip
Anyone still have the SDK for this? all the links I've found are dead :(
Goal: provide optional ssh-access (by dropbear) so that UART-access is not required any more in reference to #1
Support for cross-compiling required. thanks.