Building UnicodePlugin on ARM64

 
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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- In serious need of attitude adjustment.

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



> 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

I think this is because the configure script needs to be rebuilt.

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

Yes this is true.

Something like 'autoconf' or perhaps 'autoreconf' to generate the configure script.

As the README in the plugin directory for UnicodePlugin indicates,
an approach may be (it is a possibility) to use "pkg-config"

Assuming that pkgconfig on your system gives some results such as:

 # pkg-config --cflags glib-2.0
 # PKG_CONFIG_PATH=/usr/lib/64/pkgconfig pkg-config --cflags glib-2.0

it may be able to find the required --cflags using pkg-config

However I can imagine that approach has its own disadvantages.

My understanding is that historically pkg-config was used,
and that the opensmalltalk-vm team wants to migrate/move away from pkg-config.

If I'm not mistaken the Squeak VM "Classic" (squeak-4) uses the approach,
with cmake/pkg-config.   Squeak VM classic (in subversion) uses pkg-config.

The GNU configure script could use also the same approach using:

PKG_CHECK_MODULES(UNICODE_PLUGIN,[glib-2.0 pangocairo],,AC_PLUGIN_DISABLE)

AC_SUBST(UNICODE_PLUGIN_CFLAGS)
AC_SUBST(UNICODE_PLUGIN_LIBS)


However I agree that no approach is without faults,
they all have their own advantages and disadvantages, I suppose.

Currently on Solaris 11.4 I just disable the UnicodePlugin,
as it used to build fine for GNOME 2 (on OpenIndiana with MATE or Solaris 11.3),
but not on GNOME 3 with 64bit (Solaris 11.4) for me.

Provided I reconfigure with the right path to #include, UnicodePlugin builds,
on Solaris 11.4 as well.

This is basically unrelated to Solaris 11.3 or Solaris 11.4 etc.
It is just where Linux/Unix distributions (or operating systems in general),
put their #include files and the configuration tools to figure out the settings.

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJgKiHRAAoJEAwpOKXMq1Maxw4H/29SCg+YABqmJhd3s4LhCmnt
9fp2ogOTGFWdj4OXeBTDG0QnqTwEuJWLAruispEMiwtCoFWFoJKzpHt0yW78VjEu
vhivE/TmOVPYPAzzU1DwSjttGP5XOpul3Pl9kAZvXXR2bNece93FqKBb+6Kjb47Z
aRch60dw+XXc+ZoaxnUl4DOw5qKQQJLNq/tFIfKcYN3ZHuwUi2NGxPXtoxy9fsDY
z5hBVE3aj58X1kKyFJs9wvT2uJG8VdQReAjSHYxOxRXJaQCPhzaSMnN14KKmvGyr
GnakeHLgrUKyldvvv0FFj4u9kioYJKknRndS1tSkxbrVF1KUbrpHKrv4teDliYA=
=+siH
-----END PGP SIGNATURE-----

 
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