Re: build error
- Posted by mattlewis (admin) Apr 03, 2013
- 1741 views
It's probably not as bad as my (poor, incomplete) understanding is, but doing the translation on a more maturely supported (by/for euphoria) platform seems less risky. Of course, it doesn't hurt to try, and if it doesn't work, I don't think it will be subtle, but quick and catastrophic.
I disagree. If none of the existing eubins works, then this suggests to me that we've hit a new chip/float combo that isn't compatible with any of the existing ones - but not a maturity issue with the code itself. In this case, it is necessary to do cross-translation or even cross compiling to get a working binary - but this just means we need to build a bigger library of eubins.
Well, having enough arm eubins is part of more mature support, to me. 
Also, we don't currently have any "official" eubins for ARM. I think generous and adventurous souls have uploaded theirs.
that I couldn't use the cross compiler from my distro, because it linked to GLIBC 2.15, but raspbian uses GLIBC 2.13.
A good reason to use older distros and libraries when building software. Of course, you could have set up your own cross compiler as well - though that is a lot of extra hassle. Still, I can see the benefit of this - cross compiler on a gighertz multi-core intel box is probably faster overall than any other option (unless you have a super fast ARM processor), AND all your source code stays on the same box.
Yes, and using the software recommended by the target distro is almost always going to be easier.
I tried several things to hack around this, but couldn't get it to work. The provided cross compilers, OTOH, worked right away with no extra hacks or worrying about setting the right options to target the specific chip, since that was already baked into everything.
Wouldn't cross translation have the same benefit though? You don't need to know those options to translate the Euphoria front-end into C code, and of course once you are compiling C code on the native machine itself, all that stuff should already be set up correctly.
Right, translating is easy, and the machine on which you translate shouldn't matter at all (assuming you've set it up properly).
For all of these reasons, I suspect that we probably won't be able to offer a single binary ARM distribution of euphoria that we can expect to work everywhere.
Interestingly enough, Debian seems to. An example:
http://packages.debian.org/squeeze/lighttpd-mod-trigger-b4-dl
Another one:
http://packages.debian.org/squeeze/libc6
(Well, Debian has armel and armhf - armel is the main one, but armhf is an attempt to supercede armel iiuc with better support for hardfloat. There is also an obsolete and abandoned arm arch, which is based on some old and now obsolete binary API. http://wiki.debian.org/ArmPort )
Hmm...yes, they seem to have some kind of fake out going on between soft and hard float stuff. It's still a bit over my head. They mention runtime detection of hard vs soft float. I think we'll need to figure that out in order to get the ABI correct.
Matt
