I swear this worked a couple of weeks ago, but who knows?
I'm building a nice clean AARCH64 VM for NuScratch - which means it needs the UnicodePlugin working for the pango font rendering. I'm sure this was ok a couple of weeks ago when I tested it... but I can't see any way it could have changed. So maybe I was hallucinating.
The problem is that the glib-2.0 package is in a different path than on the 32bit ARM OS - no big surprise there , though I am surprised that the machine specific directory isn't linked to a generic path to, you know, make life less stupid. But then this is unix, where the entire idea is to make people feel stupid.
At first I thought I hadn't' installed the glib stuff properly, and indeed there are plenty of google-hits for the error message. After faffing around with that I spotted the opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/acinclude.m4 file that simply lists the (hopefully) releveant paths. Ah-Hah! thought I, add the path here and away we go. It even says that in the opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/README.UnicodePlugin
Nope.
It's also explicitly listed in opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/Makefile.inc for some reason - so let's add it there as well.
Nope.
When one examines the config.log the command to run a test prog to find out if the glib/pango/cairo stuff is there looks like this - configure:15962: gcc -c -Wall -march=armv8-a -mtune=cortex-a72 -g -O2 -DNDEBUG -DDEBUGVM=0 -DMUSL -D_GNU_SOURCE -DUSEEVDEV -DCOGMTVM=0 -DDUAL_MAPPED_CODE_ZONE=1 -pthread -DLSB_FIRST=1 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/lib/i386-linux-gnu/glib-2.0/include conftest.c >&5
Notice how it does not have the -I/usr/lib/aarch64-linux-gnu/glib-2.0/include path I've now added to acinclude.m4 Makefile.inc
And now, for added excitement, the actual opensmalltalk-vm/platforms/unix/config/configure script, which seems to also have the paths hard coded, is edited to add the new path explicitly. And at last the damned thing builds properly and even runs NuScratch.
The obvious question is what the 'proper' way to solve this is. I had the vague idea floating around the back of my skull that the 'configure' script stuff built itself from things like the acinclude.m4 fragments - and it certainly seems to include exactly the text from the original acinclude file.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- In serious need of attitude adjustment.
On Sun, Feb 14, 2021 at 01:01:22PM -0800, tim Rowledge wrote:
I swear this worked a couple of weeks ago, but who knows?
There are some recent changes to header file configurations that may not yet be completely sorted out.
For me, a recent good working version is git commit 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6 so you may want to try checking that version out (git checkout 9f1b4644e7396e473bd9bb4cf67f8a9d5a4e11d6) to see if the problem goes away. Stash your local work first before doing the git checkout.
Dave
vm-dev@lists.squeakfoundation.org