Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Aug 19 12:25
    simonedegiacomi synchronize #22
  • Aug 19 12:24
    simonedegiacomi synchronize #22
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
image.png
Ahmad Fatoum
@a3f
You dont't need a cross compiler for that btw. Just use your normal gcc with -ffree-standing and link manually against uclibc
But ye if it works out of the boz+
X*, that's a tad nicer
Simone Degiacomi
@simonedegiacomi
I compiled gcc for rpi with buildroot and it works, I also tried to run a program built for ev3 on rpi and it works (this is why I tried with gdb before), but I didn't try to run a program compiled with gcc of rpi on ev3. Wouldn't there be problems with the old headers? That's why my idea now was to compile gcc with ptxdist on rpi. Am I missing something?
Simone Degiacomi
@simonedegiacomi
I just tried, but when compiling with -freestanding and against static uclibc the linker reports a lot of errors about missing VFP register. I think I will just build the toolchain with ptxdist, so it's the same version used on x86
Ahmad Fatoum
@a3f
The trick is to not use your headers, but those of the uclibc you buiild yourself. To have the compiler not use vfp, ty -mfloat-abi=softfp, but ye, a cross compiler that just works is better
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
@a3f No problem! I don't know a whole lot about this stuff (yet), so I'm glad I could help!
Ahmad Fatoum
@a3f
@simonedegiacomi I've pushed my ptxdist setup to c4ev3/C4EV3.Toolchain. A binary release for Linux is also uploaded. I'll see what to do about other host systems.
Simone Degiacomi
@simonedegiacomi

Great, thank you!
I noticed that your configuration doesn't support pthread, am I right? I built the toolchain myself (on the rpi) and it works, I just changed these two lines in the configuration to also support pthread:

- PTXCONF_CROSS_GCC_THREADS_SINGLE=y
- PTXCONF_CROSS_GCC_THREADS="single"
---
+ PTXCONF_CROSS_GCC_THREADS_POSIX=y
+ PTXCONF_CROSS_GCC_THREADS="posix"

Last question: do you have any idea why the binaries built with this compiler weight more that the ones built with the buildroot compiler?
For the same program:
ptxbuild compiler: 1.2MB
builtroot compiler: 334KB

(same compiler flags: g++ main.cpp static-libstdc++ -std=c++11 -pthread -Os -fdata-sections -ffunction-sections, -Wl,--gc-sections)
Ahmad Fatoum
@a3f
@simonedegiacomi Try running arm-c4ev3-linux-uclibceabi-strip on both
Simone Degiacomi
@simonedegiacomi
@a3f after running that program:
ptxbuild compiler: 219KB
builtroot compiler: 183KB
now the difference is much smaller, which I think is acceptable, thank you!
Ahmad Fatoum
@a3f
@simonedegiacomi And does the pthread support work correctly? You probably want to add --enable-tls to the gcc configuration options as well, so you can have efficient thread local variables
I can add both if you can write a small program that does some thready and thready-local stuff and they work
@simonedegiacomi re executable size, could you also try by appending -s to the compiler command line and see the difference?