Glib installed into lib64

I have made a chroot jail with a cross-compiler inside it, and I’ve made my own ‘uname’ program so that every program thinks it’s running natively on 32-Bit ARM Big Endian (running inside qemu on an x86_64 desktop PC).

When I build and install Glib using meson and ninja, it puts the lib files in /lib64 instead of /lib (even though it’s built for 32-Bit ARM). This makes me think the build process is getting the CPU architecture from somewhere other than ‘uname’.

Can anybody shed some light on this? Do you know where it queries the CPU architecture from?

I am having a problem that other programs that need Glib think that it isn’t installed – I think maybe the lib64 thing is confusing it (actually I should look at the pkg-config files).

I spotted this just now in the meson build log:

Host machine cpu family: x86_64
Host machine cpu: x86_64

Obviously this is the problem. I need to find out how meson gets this information because it’s certainly not getting it from ‘uname’

It gets the CPU type in the Python file “mesonbuild/”, so I just added two lines to that file:

sed -i "352 i \ \ \ \ return \'armeb\'" ./usr/lib/python3/dist-packages/mesonbuild/  # Let meson think it's armeb
sed -i "414 i \ \ \ \ return \'armeb\'" ./usr/lib/python3/dist-packages/mesonbuild/  # Let meson think it's armeb

Rebuilding now and hoping it works.

You’re janking stuff around in ways that do not make any sense. Replacing uname and random strings in the build system isn’t going to make anything work.

You should read the Meson documentation on cross-compiling, instead of YOLO hacking your way around.

1 Like

I’ve written a Linux shell script that creates a ‘chroot jail’ and copies in basic binaries like “ls, grep, find, cp, mv” along with a few required shared libraries like “” and the interpreter “ld-linux-*.so”. This is working.

Inside the ‘chroot jail’, I’ve placed a cross-compiler that I built using ‘crosstools-ng’ to build 32-Bit Big Endian ARM programs. Since this cross-compiler is inside a ‘chroot jail’, it gets its headers from ‘/usr/include’ and its libraries from ‘/usr/lib’ as though it were a normal native compiler. This is working – I can build an ‘armeb’ program and run it with ‘qemu’.

Next I have my own “uname” program that returns “Linux armeb” (because the real program would return “Linux x86_64”). The purpose of this is to make build systems like ‘cmake’ and ‘ninja’ think that they’re building natively for armeb (so there’s no need for extra cross-compilation command line options, nor separate cross-compilation scripts).

I’ve copied in all the x86_64 build tools like ‘make, cmake, meson, ninja’. These tools use my ‘uname’ program to get the host architecture, and so they think they’re building natively from 32-Bit ARM Big Endian. This is working, I can cross-compile packages as though I were compiling natively.

So far I’ve got the following libraries built inside my chroot jail:
libffi pcre zlib fribidi libpng brotli util-linux freetype harfbuzz freetype expat fontconfig pango pixman perl cairo Python3.9

And the next libraries I need to build are:
gobject-introspection atk

I’m only a library or two away from being able to build GTK+2, and then it will really get interesting.

I’m making progress, and this will work. I’m making a ‘chroot jail’ which will serve as a build system for the Linux distro I’m making.

This is still not a good idea, uname is implemented with a system call so it will work up until you find a program that calls the syscall manually instead of forking out to the utility. It also will be pretty broken if you try to compile anything that needs to build utilities for the host system as part of the compile. It is about as good an idea as trying to mess around with CC and CFLAGS to change the target system, i.e. not by much. Also GTK2 is quite old. I don’t know if I could suggest building a Linux distro with it.

Any new executable program inside the chrootjail will have been built inside the chrootjail, and so it will be an armeb binary. Therefore it will run in ‘qemu’, and ‘qemu’ will handle the syscall.

I have already built Boost, which as a part of the build process creates an executable file to continue the build process (i.e. the new executable file runs in qemu).

For the moment I have GTK+2 because that’s what’s on the Raspberry Pi. Might upgrade to 3 or 4 though.

What I’m putting together at the moment is working.

In my experience qemu is quite slow and probably should be avoided if you can, this is why meson handles this natively: Cross compilation

If you switch to GTK 3 or 4 then you can just use meson’s native cross compiling and don’t need to bother with those hacks.

I only use qemu for small little programs like “b2” for building Boost, or “meson” or “ninja”.

All the intensive work is done by x86_64 binaries living inside my chrootjail. All of the compilation is done by “gcc” which is a symbolic link to “arm-unknown-linux-gnueabi-gcc” which is an x86_64 binary that produces armeb ELF files. It’s fast.

I have my chrootjail on a 40-core workstation here at home, so I can build programs and libraries quickly.

When we’ve finally produced a Big Endian distro for 32-Bit raspberry pies, I’ll be able to use the chrootjail to build things a lot quicker than if I built them natively on the raspberry pi.

That is not necessary, as was mentioned before meson has native support for cross compilation and boost b2 has support for it too: Cross-compilation

It’s pure convenience being able to untar source code and just follow the normal instructions. 75% of the time it’s just “./configure && make && make install”. Sometimes it’s cmake though, and now and again it’s meson+ninja. Yes I realise that most GNU Makefiles allow for cross-compilation with PREFIX=, and also cmake and meson can be configure to cross-compile, but I just don’t want to know about that.

And of course it’s beneficial for packages that don’t support cross-compilation. Some programs and libraries had their compilation scripts written in such a way that they’d need significant going over to enable cross-compilation.

Also this is fun.

I got it working this evening. Inside a chrootjail on an x86_64 desktop PC, I have a build system for 32-Bit Big Endian ARM, and all the build tools think they’re running natively on a 32-Bit Big Endian ARM processor.

This evening I finally got gtk+2 and its ~15 dependencies built, closely followed by wxWidgets, Boost and libPcap.

Lastly I was able to build my own Dynamo program as a 32-Bit Big Endian ARM binary, and I ran it in QEMU inside the chrootjail. It works.

I’m going to zip up my chrootjail into a tarball and share it. It’s pretty much the guts of a Linux distro. I reckon I’m about 30 - 40% of the way to making a 32-Bit Big Endian ARM Linux distro to run on the 32-Bit Raspberry Pi 2.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.