machinekit-hal icon indicating copy to clipboard operation
machinekit-hal copied to clipboard
verified publisher icon machinekit

Debian packaging needs Multi-Arch: fixes

Open zultron opened this issue 5 years ago • 4 comments

It's not possible to cross-build linuxcnc-ethercat packages because the machinekit-hal packages are completely lacking Multi-Arch: compatibility. Here are some of the first things I see that need to happen:

  • machinekit-hal-dev package:
    • Shared rtapi.h file contains SIZEOF_* macros that are architecture dependent; these should be factored out
  • machinkeit-hal package:
    • /usr/lib/lib*.so.0 libs need to be split out into a separate e.g. libmachinekit package marked Multi-Arch: same (and they need to be installed to /usr/lib/$DEB_BUILD_MULTIARCH)
    • /usr/lib/{rtapi,shmcommon,compat,hal}.so look like copies of their ./usr/lib/python3/dist-packages/machinekit/*.cpython-*.so counterparts and need to be removed

zultron avatar Sep 04 '20 16:09 zultron

@kinsamanka in his #250 had in-progress something similar. You can look at his control.in file. I remember that I was excited for this change at the time, because it furthers the encapsulation, but at the same time worried he is putting multiple changes to one pull request and that he is going to run himself to the ground.

But implementing this issue could take and build on top of work started in that PR.

cerna avatar Sep 04 '20 18:09 cerna

Oh boy, Makefile.inc is full of arch-specific variables, and it's sourced by Makefile.modinc. These are both installed by the machinekit-hal-dev package, which is supposed to be arch-independent.

We could install an arch-specific Makefile.inc file with the libmachinekit package, but that's not clean, since it mixes in dev files with a non-dev package. But stepping back, the whole Makefile.inc idea is an abomination to begin with.

I can get around this when cross-building the linuxcnc-ethercat package by querying pkg-config. I don't remember if I solved this properly for the EMC application's build system, but if not, it'll come around to bite us when integrating CI there.

zultron avatar Sep 06 '20 22:09 zultron

I'm looking a little deeper at how to replace Makefile.modinc. I had forgotten the comp scripts use it.

Fundamentally, autoconf (CMake, someday) is going to have to stick build data into some file, somewhere of some type, in some package. It won't be practical, from a script, to try and guess paths of & arguments to the local arch-specific gcc, ld and objcopy, given a build-arch GNU host triplet (aarch64-linux-gnu, x86_64-linux-gnu), and especially in a distro-independent way or without dragging in even more baggage. So this stuff needs to be recorded at build time into a file. That's what Makefile.modinc does, but I think we can do better. I'm looking for something standard, something that is architecture-aware, and something that can manage this information for multiple host triplets on the same host.

These arch-specific build data files belong in the -dev package. I was initially concerned about file overlap, since e.g. common header files belong in the common /usr/include, but I've seen dpkg complain about file collisions between packages. This appears not to be a concern, since other -dev Debian packages do exactly this, e.g. libavahi-common-dev (marked Multi-Arch: same), with files in non-overlapping, arch-specific locations (e.g. /usr/lib/aarch64-linux-gnu/libavahi-common.a) and in overlapping, arch-independent locations (e.g. /usr/include/avahi-common/domain.h). This clears the way for putting arch-specific files in the -dev package.

The EMC build system rework already introduced a pkg-config file for machinekit-hal. Happily, there are arch-specific pkg-config versions, e.g. aarch64-linux-gnu-pkg-config, that look in a few arch-specific locations like /usr/lib/aarch64-linux-gnu/pkgconfig, in addition to the usual common paths.

I'm leaning toward this scheme, because it fits all the requirements. The machinekit-hal.pc file in /usr/lib/${HOST_TRIPLET}/pkgconfig will hold all needed build data needed by the comp scripts to build out-of-tree modules. That's also a good interface for projects with simple makefiles to extract just the variables they need. Projects using Autoconf or CMake can use those tools' native pkg-config integration to extract build parameters (although it would be nicer to provide Autoconf macros or a CMake "find" script).

zultron avatar Sep 07 '20 04:09 zultron

Handy links re. Multi-Arch: https://wiki.ubuntu.com/MultiarchCross https://wiki.debian.org/Multiarch/Implementation

zultron avatar Sep 07 '20 16:09 zultron