Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 17 13:33
    Electrenator commented #26
  • Oct 17 13:32
    Electrenator commented #26
  • Oct 11 23:05
    dnlmlr commented #26
  • Oct 11 23:05
    dnlmlr commented #26
  • Oct 11 23:04
    dnlmlr commented #26
  • Oct 11 22:39
    Electrenator commented #26
  • Oct 11 11:50
    dnlmlr commented #26
  • Oct 11 11:42
    Electrenator opened #26
  • Oct 04 11:57
    simonedegiacomi commented #25
  • Oct 04 11:39
    dnlmlr commented #25
  • Oct 01 12:28
    Jensonbruins commented #25
  • Oct 01 12:23
    dnlmlr commented #25
  • Oct 01 12:11
    Jensonbruins opened #25
  • Sep 27 17:06
    dnlmlr commented #24
  • Sep 27 15:40
    WilliamRagstad opened #24
  • Aug 22 14:47
    simonedegiacomi synchronize #22
  • Aug 20 16:50
    simonedegiacomi synchronize #22
  • Aug 20 11:58
    simonedegiacomi synchronize #22
  • Aug 19 14:18
    l-yc opened #23
  • Aug 19 13:05
    simonedegiacomi synchronize #22
Ahmad Fatoum
@a3f
@AnarCom So you can upload file via the file system dialog in Eclipse, but not by directly running ev3duder from command line?
Simone Degiacomi
@simonedegiacomi
@a3f thank you!
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
I've recently compiled the toolchain on the new OSELAS.Toolchain-2018.12.0 branch, but I'm not sure it's fully working. I've built it on two separate machines running Ubuntu 18.04.2, so I'm very certain it built correctly.
The default Hello World EV3 C project compiles successfully, and I can upload the files to the EV3 without issues, but nothing seems to happen.
I know it's an issue with the toolchain, because when compiled with the CodeSourcery toolchain, it runs successfully.
Not sure what needs to change; just letting you know I've tested it.
dnlmlr
@dnlmlr
If you have a compatible wifi stick, you can log into the EV3 using telnet and run the program there from the shell. That gives the most information in my experience.
Simone Degiacomi
@simonedegiacomi
I also tried to compile the toolchain (using Ubuntu 19.04 with ptxdist v2019.07.0) and got the same result. When I start the program from the shell (using telnet) I get a segmentation fault
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
I was experimenting around with making my own toolchain for the EV3, and I think I've stumbled across a really simple solution.
I ended up downloading buildroot-2019.05.01 (https://buildroot.org/downloads/buildroot-2019.05.1.tar.bz2) and creating a simple defconfig (https://drive.google.com/file/d/1ijBXhfV_KiHDWhg3d5yVaX4H_jut63g8/view?usp=sharing).
Here's the steps I took to make a working toolchain:
1) Unpack the buildroot tarball
2) Copy c4ev3_defconfig into the buildroot-2019.05.1/configs directory
3) Open the buildroot-2019.05.1directory in the terminal
4) Enter make c4ev3_defconfig
5) Enter make toolchain
6) Sit back, relax.
You'll find your new toolchain in buildroot-2019.05.1/output/host/.
I built this toolchain inside an Ubuntu 18.04.2 VM, and it has worked for me so far. I've compiled and run the C and C++ Hello World programs without issue.
Hopefully this helps :D
Ahmad Fatoum
@a3f
@simonedegiacomi @OurLordAndSaviorStickles Thanks both for testing. Hmm a segfault.. I wonder why that happens..
Simone Degiacomi
@simonedegiacomi
@a3f thank you for your effort to provide a toolchain! Feel free to ask for tests if it's needed. Right now I'm building the toolchain as @OurLordAndSaviorStickles has suggested, I will report my results when the compilation finishes
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Nice. I am not used to Buildroot, but I don't object to adopting it. The config needs some changes though. We need to use either an older glibc explicitly or uclibc. Otherwise we risk linking applications that don't work on the EV3. Could you amend your defconfig to use the newest uclibc? Also I see no where a config option about the ARMv5T. I think we need that to not risk the compiler generating instructions that aren't supported on the ARM9 at higher optimization levels.
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
@a3f Yeah, the config could probably be improved by explicitly setting more options. I was just trying to get it done quickly, and relied on a lot of the default settings.
Here's an updated version, with a few of the default settings explicitly defined (https://drive.google.com/file/d/1_O1iexITacZBHqDWwxGv1bwmhNDE9HWU/view?usp=sharing)
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Great. The only question is how we will get a Windows Toolchain out of this.. Can you do a canadian cross compile (--build=x86-linux --host=windows-x86 --target=arm-linux) with buildroot?
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
@a3f It doesn't look like Buildroot can do this. It's handy for Linux, but we'll need another method for a Windows toolchain. Unfortunately, I have very little experience in this matter, so I'm not sure what the best approach would be :/
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles The uclibc builds works fine for you? Could you run your toolchain's gcc -Q -v, so I can compare it with OSELAS' one?
OSELAS.Toolchain doesn't support canadian cross either, but I rather try to extend that one because the maintainer sits one office over at work and I am used to PTXdist.
dnlmlr
@dnlmlr
Maybe
*Maybe docker could be utilized to create a build environment to reliable build the toolchain. Cross compiling for windows should be also possible this way.
Our Lord And Savior Stickles
@OurLordAndSaviorStickles

Buildroot:

$ arm-c4ev3-linux-uclibcgnueabi-gcc -Q -v
Using built-in specs.
COLLECT_GCC=/home/stickles/buildroot-2019.05.1/output/host/bin/arm-c4ev3-linux-uclibcgnueabi-gcc.br_real
COLLECT_LTO_WRAPPER=/home/stickles/buildroot-2019.05.1/output/host/libexec/gcc/arm-c4ev3-linux-uclibcgnueabi/8.3.0/lto-wrapper
Target: arm-c4ev3-linux-uclibcgnueabi
Configured with: ./configure --prefix=/home/stickles/buildroot-2019.05.1/output/host --sysconfdir=/home/stickles/buildroot-2019.05.1/output/host/etc --enable-static --target=arm-c4ev3-linux-uclibcgnueabi --with-sysroot=/home/stickles/buildroot-2019.05.1/output/host/arm-c4ev3-linux-uclibcgnueabi/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/home/stickles/buildroot-2019.05.1/output/host --with-mpc=/home/stickles/buildroot-2019.05.1/output/host --with-mpfr=/home/stickles/buildroot-2019.05.1/output/host --with-pkgversion='Buildroot 2019.05.1' --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath --disable-libsanitizer --enable-tls --disable-libmudflap --enable-threads --without-isl --without-cloog --with-float=soft --with-abi=aapcs-linux --with-cpu=arm926ej-s --with-float=soft --with-mode=arm --enable-languages=c,c++ --with-build-time-tools=/home/stickles/buildroot-2019.05.1/output/host/arm-c4ev3-linux-uclibcgnueabi/bin --enable-shared --disable-libgomp
Thread model: posix
gcc version 8.3.0 (Buildroot 2019.05.1)

OSELAS:

arm-c4ev3-linux-uclibceabi-gcc -Q -v
Using built-in specs.
COLLECT_GCC=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/bin/arm-c4ev3-linux-uclibceabi-gcc
COLLECT_LTO_WRAPPER=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/libexec/gcc/arm-c4ev3-linux-uclibceabi/8.2.1/lto-wrapper
Target: arm-c4ev3-linux-uclibceabi
Configured with: ../gcc-8-20181130/configure --build=x86_64-host-linux-gnu --host=x86_64-host-linux-gnu --target=arm-c4ev3-linux-uclibceabi --with-build-sysroot=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/sysroot-arm-c4ev3-linux-uclibceabi --with-sysroot=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/sysroot-arm-c4ev3-linux-uclibceabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-linker-build-id --disable-libsanitizer --enable-c17 --enable-c++17 --with-bugurl=https://github.com/c4ev3/C4EV3.Toolchain --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion='C4EV3.Toolchain-2019.08.0 8-20181130' --enable-threads=single --with-system-zlib --with-gmp --with-mpfr --with-mpc --with-isl --with-debug-prefix-map='= WORKSPACE/platform-=C4EV3.Toolchain-2019.08.0/platform-' --enable-libstdcxx-debug-flags='-gdwarf-4 -O0 -g3 -gno-record-gcc-switches' --prefix=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized --enable-languages=c,c++ --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --disable-shared --disable-libssp --enable-checking=release
Thread model: single
gcc version 8.2.1 20181130 (C4EV3.Toolchain-2019.08.0 8-20181130)
Ahmad Fatoum
@a3f
@dnlmlr You mean a docker containter for compiling or using the toolchain? The latter indeed sounds like a good idea. Would save the hassle and we could just ship the Linux compiler
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Just to be sure, even a hello world (int main(void) { puts("Hello World"); }) crashes? How about an empty int main(void) {}?
Simone Degiacomi
@simonedegiacomi

I will report my results when the compilation finishes

I built the compiler using the second config file suggested by @OurLordAndSaviorStickles and it works also for me, although I need to compile with the -static flag, otherwise I get a "file not found error"

@OurLordAndSaviorStickles Just to be sure, even a hello world (int main(void) { puts("Hello World"); }) crashes? How about an empty int main(void) {}?

@a3f If it's the same problem that I have, also int main(void) {} crashes

Ahmad Fatoum
@a3f
@simonedegiacomi I think --disable-shared should make -static the default.
Simone Degiacomi
@simonedegiacomi
that flag needs to be specified when building gcc, right?
Ahmad Fatoum
@a3f
@simonedegiacomi yes. I already pass that in the OSELAS config. I think I might need to pass --with-abi=aapcs-linux to the OSELAS gcc configure. Would you be willing to run an ELF file I compile for you on the EV3, so we can try this out?
Simone Degiacomi
@simonedegiacomi
yes, no problem
Ahmad Fatoum
@a3f
@in
This one's compiler has --with-abi=aapcs-linux added and --fpu=vfp removed.
Simone Degiacomi
@simonedegiacomi
image.png
Ahmad Fatoum
@a3f
meh.. @simonedegiacomi you got gdb or something to get some more info why it crashes?
Ahmad Fatoum
@a3f
An invalid system call number is punished by a seg fault as well IIRC, strace would show that. hmm.. I am recompiling again with a different uclibc config
Simone Degiacomi
@simonedegiacomi

meh.. @simonedegiacomi you got gdb or something to get some more info why it crashes?

I can't run gdb on the EV3, but I tried to run it on a raspberry (I know it's not the same architecture, but it semes to work). When running the program I get:

(gdb) run
Starting program: /tmp/hellow.elf 

Program received signal SIGSEGV, Segmentation fault.
x00011c68 in strchr ()
Ahmad Fatoum
@a3f
Great. Ok, I'll do hopefully the last toolchain build now and look into packaging that one as docker containers
Simone Degiacomi
@simonedegiacomi
which flags did you use for the build of hellow2?
Ahmad Fatoum
@a3f
@simonedegiacomi I tried the buildroot uclibc config, I am changing it a bit to always statically link now.
That way we shouldn't need -static
Simone Degiacomi
@simonedegiacomi
so you're going to use buildroot instead of ptxdist?
Ahmad Fatoum
@a3f
@simonedegiacomi The OSELAS problem was with the uclibc config, which I had based on a uClinuc config that wasn't compatible it seems. With this fixed, both work now.
I'd go with OSELAS/PTXdist. Less learning curve for me ^^'
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Thanks by the way for the buildroot config. Very helpful to see what I was doing wrongly before : )
Simone Degiacomi
@simonedegiacomi
ok understood. thank you for trying the different configurations, I didn't know where to start. When you'll commit the new configuration I will run the build for the raspberry pi (I need the compiler for that), if it may be useful also for others I can share it
One is C and the other C++.
There isn't a shortage on cross-compilers for the raspberry pi, why do you want to build your own?
Simone Degiacomi
@simonedegiacomi
I don't need the crosscompiler for raspberry pi, I need the compiler that runs on raspberry pi to compile programs for EV3 😄

One is C and the other C++.

they both work :thumbsup:

Ahmad Fatoum
@a3f
@simonedegiacomi great :) they print to stdout correctly as well?
Simone Degiacomi
@simonedegiacomi
@a3f yes