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.

I used cross-compile because I built my own barebones linux system with musl + busybox, (and with my own toolchain), so building the VM directly on the device (which runs my very lightweight embedded linux system) is not an option for me in this case

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

Hi, making the change to config.sub is fine. What I don't get is the explicit definition for struct _IO_FILE in sqVirtualMachine.c. Shouldn't we do something like

#if TheDefimneThatSaysWereUsingMUSL

include <whereever/lives/stdio.h>

#endif

The key here is to not break the existing build, and including a possibly incompatible definition of struct _IO_FILE in sqVirtualMachine.c is almost guaranteed to break the build somewhere :-)

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

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:

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.

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

Then I think the best thing to do is simply to #ifdef out the stdoutStack, pushOutputFile, and popOutputFile code on Musl. What is the define that indicates that Must is being used?

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

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:

#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.

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

Didn't see this earlier. I've built the VM on Alpine Linux, which is also Musl. I don't remember having to modify the source. Did have to modify CMake files to link against some more libraries.

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

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

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

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

Replying to my own comment, I've now put up my modifications to the source tree in the pierce_alpine branch of my fork. It is for building pharo.cog.spur.minheadless on Alpine Linux x86_64. I've not tried building VMs for the other Smalltalks.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Closed #304.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.