Sorcery g++ Cannot find libc.so.6

[matanui159]

I finally got around to using c4ev3, and I'm having issues with the addon/compiler. I posted here as I couldn't find any bug reports for Sorcery and my last issue I posted on one of the other c4ev3 repo's showed that you reply quick with great help.

When I try to compile I get this error:
c:/program files (x86)/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld.exe: cannot find /lib/libc.so.6 inside c:\program files (x86)\codesourcery\sourcery g++ lite\bin\../arm-none-linux-gnueabi/libc/armv4t

I checked that directory and it contains a file called /lib/libc-2.8.so but no /lib/libc.so.6 which seems to be the problem. I've tried adding -nostdlib then `-lc' to see if that fixed anything but neither flags seem to change anything at all.

[a3f]

Maybe a botched install? libs.so.6 is a symlink to the actual libc-*.so, but Windows doesn't understand UNIX symlinks.

Lazy solution: Try duplicating libc-*.so with a new name: libc.so.6

Proper solution: 4.3.3 is ancient (in internet years at least; it was released 8 years ago). You might want to use a more up-to-date toolchain. Chances are its setup will handle these symlinks properly.

[matanui159]

Why don't you include a more up to date version?

[a3f]

Heh, I hoped that wasn't ours, but was too lazy to check. Well, in my defense it was less ancient (25%!) when I packaged the installer.

But I can speak to the fact that the installer we ship does work. Have you tried reinstalling? Did duplicating the libc with the expected name work?

I believe CodeSourcery doesn't provide newer CS Lite toolchains for Windows anymore. Or maybe they do, but their website has become difficult to navigate after Mentor Graphics took over and I couldn't manage to find a direct link to a more up-to-date toolchain, so I went with that one.

If you do find a recent arm-none-linux-gnueabi-gcc (more specific: /arm-(none-)?linux-(gnu)?eabi-gcc/), please share and I could update the installer. I usually build the cross toolchains I use myself, but I am less enthusiastic about trying to do so on Windows.

[matanui159]

It sort of worked, but with more issues. Firstly ld-linux.so.3 then arm-none-linux-gnueabi-objcopy.exe didn't exist, but after I copied and renamed those files, it compiled and uploaded (yay) but did not run (awww). The file was nowhere to be seen on the EV3, and "Upload and Run" makes the EV3 show a loading animation but it seems to crash.

Maybe its due to this warning?
arm-none-linux-gnueabi-g++: unrecognized option '-static-libstdc++'

[a3f]

Ye, that's a deal breaker. From the ev3duder documentation:

stdlibc++ is not provided by default and would need to be uploaded separately and dynamically loaded or linked statically (e.g. by specifying -static-libstdc++ during linking with GCC 4.5+).

Either upload the libstdc++ manually. (There is a file manager in the Eclipse plugin, you can use for that), use a cross GCC ≥4.5 or use C.

[matanui159]

Could you maybe use another ARM toolchain other than Sorcery?

[a3f]

Got a specific one in mind? As I said, if you find a reputable vendor who provides prebuilt windows binaries, I'd be happy to include them.

[matanui159]

A quick search found this.

It's seems like an official toolchain, has windows binaries, and last update was a month ago.

[matanui159]

I'm uninstalling Sorcery G++ and seeing if I can get this official toolchain working right now.

EDIT: Turns out I was wrong, that toolchain was barebone when I believe a linux toolchain is needed. I did find this however, which I am now testing. (I am using 32-bit ARMv7 Cortex-A, hard-float, little-endian, i686_mingw32)

[matanui159]

Update, back to the same issue: compiles, uploads but does not run. This time using Linaro with C.

[a3f]

I had the same problem with Linaro, but I can't recall if I investigated the reason. If I were to take a guess now, I'd say it's a libc version mismatch. You can use ev3duder exec from the command line to run commands (or applications) with their stdout and stderr redirected to the USB connection.

If you are fine with the existing C++98 support, just upload the libstdc++.so.* to /usr/lib and keep using the CodeSourcery toolchain we ship as usual:

ev3duder up "c:/program files (x86)/codesourcery/sourcery g++ lite/lib/libstdc++.so.6" /usr/lib

[matanui159]

Ok, that fixed it (well, I just switched to C and that fixed it [I don't even know why I set it up for C++ when I actually prefer and was planning to use C]).

But the program isn't showing up on the list? I have to manually plug it in and use "Upload and Run" to get it to run. I've tried manually uploading it with:
ev3duder up test.rbf ../apps/test.rbf
but still no luck.

[a3f]

Does it show up when uploading to the memory card, or do you do that already?

There's a ev3duder run command by the way, to run RBFs, independent of the menu.

[matanui159]

It does show up from the SD card I believe but I haven't tested it. I would rather it just be on the EV3 itself. I also can't start it from a computer because these will be used for RoboCup.

[a3f]

The EV3 is a bit pedantic about the directory layout. For example on the SD card, it wants the rbf files to be in a subdirectory. I don't have an EV3 to test, but I recall that it was showing up in the menu when using the internal memory.

Did you change start.lms, directly or indirectly via the wizard?

Also best of luck with your RoboCup endeavors. I shall root for those using my software :D

[matanui159]

No, what is start.lms and what is it used for? Am I supposed to change it?

[a3f]

Only .rbf files in specific locations get a menu entry, so the EV3 hello world project contains a start.lms that gets compiled to a rbf that calls the actual C program.

Changing it could make the icon disappear, so better keep it as-is. It should say:

define starter '${brick}/myapps/${projectName}.rbf'
define elfexec '${brick}/${projectName}.elf'

at the top, does it?

[matanui159]

Sorry, I've been busy the past day and a half, but I just checked now and it does start with that.

EDIT: I've also reset the EV3 and gone through with ev3duder ls and all files seem to be in their correct spots, however I did notice that the Demo program has a Demo.rpf in /home/root/lms2012/prjs/BrkProg_SAVE rather than a .rbf in /home/root/lms2012/prjs/BrkProg_SAVE/myapps

[a3f]

There's an integrated File Manager in Eclipse:
Window Menu -> Show View -> Other -> Other -> EV3 File System, which you might want to use for navigation and file copying.

I can't remember what .rpf files are for, but I understand everything is working fine now? If so, please close the issue.

[matanui159]

No, it still doesn't work properly, sorry. The program still doesn't appear in the EV3 program list.

[a3f]

I just checked now and it does start with that

Starts with what? So it works from SD Card but not from the Brick memory? Did you try in both cases the Hello World C example without any modifications?

[matanui159]

Sorry I wasn't very clear. start.lms starts with those lines of code.

[a3f]

That's unfortunate. Well, no idea what's wrong. I do recall that there were menu entries with brick memory. The documentation also reflects that:

$ ev3duder up test.elf ../prjs/BrkPrg_SAVE/test
$ ev3duder mkrbf /home/a3f/lms2012/BrkPrg_SAVE/test test.rbf
$ ev3duder up test.rbf ../prjs/BrkPrg_SAVE/test.rbf
$ ev3duder run test.rbf

It speaks of RBFs though, not RPFs. Try following these steps and see if it works for you. Apart from that, menu entries for programs on SD memory works out-of-the-box, because that's what we were using primarily, so you could always try that instead of brick memory. Unfortunately, I don't have an EV3 to test on, so I can't offer more help.

[a3f]

I built some new toolchains at https://github.com/c4ev3/toolchain. The Linux and macOS toolchains should work and support -static-libstdc++. The Windows Toolchain still has some issues though. I will report back here should I get around to fix it...