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.