Hello to anotherARM VM maker; nice to know I'm not the only one ...

Why use cross-compiling? You know the Pi can perfectly happily compile & build for itself, right? That's the only build I ever use. Do the build on a Pi3b+ and it takes not very long at all.

On 2018-11-09, at 1:32 AM, Xuan Sang LE notifications@github.com wrote:

Hello,

I have a small issue when building (cross-compile) the Smalltalk VM on an ARM(v6) embedded linux system (Nano Pi neno and Raspberry Pi Zero) that uses Musl as default libc implementation.

The problem is that the code and the configure script does not have official support for Musl, so I created a patch file that adds support to Musl, you can find the patch here.

With this patch, i am able to cross-compile on the ARM toolchain for my system; with 4 plugins:

FilePlugin \ SqueakSSL \ SqueakFFIPrims \ SocketPlugin

You can find the build script here

For now, i can live with this dirty trick, but i would be verry happy if the mainline VM has official support to Musl.

That's why i create this issue.

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Utinam logica falsa tuam philosophiam totam suffodiant! = May faulty logic undermine your entire philosophy!

Hello, It is indeed a dirty hack, the ```stdio.h``` is already in the include path, but i realized that in Musl, only the definition of FILE is available in stdio.h, the struct **_IO_FILE**, however, is not publicly defined (i.e. it is not available in the public headers). That cause an error about incomplete type definition when gcc tries to compile the line: ```c static FILE stdoutStack[STDOUT_STACK_SZ]; ``` So i put the explicit definition to the ```sqVirtualMachine.c```, it works for me, but, is indeed not a good solution. What we can do is to put that definition somewhere else, and only include it in ```sqVirtualMachine.c``` if we are using Musl as lib implementation.

I just do a check, there are two minor problems with Musl:

1. Musl does not provide any predefined macro in order to test for its presence, like GLIBC 2. The struct _IO_FILE is defined in ```src/internal/stdio_impl.h```, but it is not a public API and is subject to change in the future.

For the fist problem, we can just use some thing like this: ```c #ifdef __MUSL__ // do some stuffs #endif ``` Then, when one want to compile again Musl, just add the ```-D__MUSL__``` to the ```CFLAGS``` when executing the configure script.

For the second problem, the added explicit definition (as i did) is not guaranteed to work in the future version of Musl since the ```struct _IO_FILE``` may be changed. It would be nice if we can find a workaround that does not involve the (re)definition of that struct.

Could you share your modification (i.e. the CMake)? Modifying the source works for me, but I'm not really happy about it :-)

Replying to my own comment, I've now put up my modifications to the source tree in the ```pierce_alpine``` branch of [my fork](https://github.com/PierceNg/opensmalltalk-vm/tree/pierce_alpine). It is for building ```pharo.cog.spur.minheadless``` on Alpine Linux x86_64. I've not tried building VMs for the other Smalltalks.