Repository navigation
Debian packaging needs Multi-Arch: fixes #310
Description
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-devpackage:- Shared
rtapi.hfile containsSIZEOF_*macros that are architecture dependent; these should be factored out
- Shared
machinkeit-halpackage:/usr/lib/lib*.so.0libs need to be split out into a separate e.g.libmachinekitpackage markedMulti-Arch: same(and they need to be installed to/usr/lib/$DEB_BUILD_MULTIARCH)/usr/lib/{rtapi,shmcommon,compat,hal}.solook like copies of their./usr/lib/python3/dist-packages/machinekit/*.cpython-*.socounterparts and need to be removed
Activity
cerna commentedon Sep 4, 2020
@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.
zultron commentedon Sep 6, 2020
Oh boy,
Makefile.incis full of arch-specific variables, and it's sourced byMakefile.modinc. These are both installed by themachinekit-hal-devpackage, which is supposed to be arch-independent.We could install an arch-specific
Makefile.incfile with thelibmachinekitpackage, but that's not clean, since it mixes in dev files with a non-dev package. But stepping back, the wholeMakefile.incidea is an abomination to begin with.I can get around this when cross-building the
linuxcnc-ethercatpackage by queryingpkg-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 commentedon Sep 7, 2020
I'm looking a little deeper at how to replace
Makefile.modinc. I had forgotten thecompscripts 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-specificgcc,ldandobjcopy, 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 whatMakefile.modincdoes, 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
-devpackage. I was initially concerned about file overlap, since e.g. common header files belong in the common/usr/include, but I've seendpkgcomplain about file collisions between packages. This appears not to be a concern, since other-devDebian packages do exactly this, e.g.libavahi-common-dev(markedMulti-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-devpackage.The EMC build system rework already introduced a
pkg-configfile formachinekit-hal. Happily, there are arch-specificpkg-configversions, 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.pcfile in/usr/lib/${HOST_TRIPLET}/pkgconfigwill hold all needed build data needed by thecompscripts 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' nativepkg-configintegration to extract build parameters (although it would be nicer to provide Autoconf macros or a CMake "find" script).Multi-Arch: support: Split out `libmachinekit` package
Multi-Arch: support: Split out `libmachinekit` package
zultron commentedon Sep 7, 2020
Handy links re.
Multi-Arch:https://wiki.ubuntu.com/MultiarchCross
https://wiki.debian.org/Multiarch/Implementation
Multi-Arch: support: Split out `libmachinekit` package