Thanks for the support! I managed to even get a package build to work -- I had to install the rest of the gtk libraries which I was skipping before with disable-gtk, several of which required the manual copying trick. I also had to add a bit to the debuild line (again for my own reference): debian/configure -r PKG_CONFIG_PATH="/usr/lib/arm-linux-gnueabihf/pkgconfig/" debuild - eDEB_BUILD_OPTIONS=parallel=4 -us -uc -d -j4 -d -b -aarmhf
I guess in terms of documentation, it would be convenient if the main build from source docs referenced the latest docker image and build repo: http://www.machinekit.io/docs/developing/machinekit-developing/. I found several references online to arceye's docker image, where proot-helper errored out. After trying several docker images referenced online, I gave up and went on this wild goose chase to do the full cross-compile in my own chroot environment. And now I can finally work on the REAL project I needed -- getting UVW blending to work! https://github.com/LinuxCNC/linuxcnc/tree/feature/uvw-blending-dev The yak shaving continues... On Sunday, April 21, 2019 at 9:28:08 PM UTC-7, John Morris wrote: > > James, > > Very nice! This is not an easy thing to do. As Mick said, we do > something very similar, all inside Docker containers, to speed up armhf > builds on the amd64-arch CI systems the project uses to run tests and > builds. > > Building packages is an additional challenge, and requires installing even > more package dependencies alongside the build-arch tool chain to get > `dpkg-buildpackage` even to *agree to try* building your packages! > > The basic trick we use to get around incomplete `MultiArch` support is to > install conflicting packages in a multistrap root under `/sysroot`, and > tell the compiler and linker to grab headers and libraries from there with > the `gcc --sysroot=/sysroot` argument. After that, the real fun begins! > Your `libboost-python-dev` hack is a good example of the many tricks we use > to make this work, and the result is a big, stinky mess. > > Happily, Docker neatly contains all this ugliness in an image that's easy > to reproduce and easy to run, both in the project's CI systems and in our > developer environments. You can see what exactly goes into it in the below > GitHub repository (PRs are very welcome if you can improve it). Hopefully > these kinks in `MultiArch` will be worked out some day and this will all be > much simpler. > > https://github.com/zultron/mk-cross-builder > > John > > ________________________________________ > From: machi...@googlegroups.com <javascript:> <machi...@googlegroups.com > <javascript:>> on behalf of schoo...@gmail.com <javascript:> < > schoo...@gmail.com <javascript:>> > Sent: Saturday, April 20, 2019 8:56 PM > To: machi...@googlegroups.com <javascript:> > Subject: Re: [Machinekit] Successful cross-compiling with Debian Stretch > > Hi James, > > I went on a similar journey a few years ago, first using a chroot file > system and qemu and then multiarch cross builds. > You learn a lot on the way and the latter is certainly faster. > > We have been using John Morris's multiarch cross compiling docker > containers for a while now. > They use the same approach as you did. > > If you install docker-ce and checkout > dovetailautomata/mk-cross-builder:armhf_9 from dockerhub, you can build > your packages with > `scripts/build_docker -t armhf_9 -c deb -j $(nproc)` > from the root dir of the machinekit repo. > > That is how we produce all the machinekit packages now and it works well > locally too. > > regards > > > > > On 19/04/19 17:30, James Gao wrote: > Hi everyone, > Just wanted to report that I got Machinekit to successfully cross-compile > through a Debian Stretch debootstrap. It seems that the latest multiarch > support in stretch is good enough that (most) of the armhf libraries > installed correctly. This doesn't require qemu, so it takes a fraction of > the time to build. I was searching for more instructions on how to do a > cross-compile build, and came across this thread: > https://groups.google.com/forum/#!topic/machinekit/HWS807SS8ks< > https://groups.google.com/forum/#%21topic/machinekit/HWS807SS8ks> which > requested a PR -- let me know if that's still preferred. > > This is partially for my own benefit, but here's a short summary of the > commands I used to get it to work: > sudo debootstrap --components=main,contrib,non-free stretch {DEST_FOLDER} > http://deb.debian.org/debian/ > > I configured schroot to launch the system: > cat <<EOF > /etc/schroot/chroot.d/amd64-stretch > [amd64-stretch] > description=Debian Stretch (amd64) > directory={DEST_FOLDER} > root-users={USERNAME} > users={USERNAME} > type=directory > EOF > schroot -s amd64-stretch > > Once inside, I configured multiarch and installed some basic packages: > sudo dpkg --add-architecture armhf > sudo apt update > sudo apt install gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf cython > pkg-config autoconf git libczmq-dev:armhf > git pull https://github.com/machinekit/machinekit.git > cd machinekit/src/ > ./autogen.sh > PKG_CONFIG_PATH="/usr/lib/arm-linux-gnueabihf/pkgconfig/" ./configure > --with-platform-beaglebone --host arm-linux-gnueabihf > > Now the great dependency hunt begins -- basically just run the configure > line, and install the :armhf version of whatever library it complains > about. I can put together a more comprehensive list if requested. > > The only library that requires special treatment is libboost-python-dev. > If you try to install the :armhf version of that library, it tries to > replace python with the armhf version, which will break the system. I went > ahead and just directly extracted only the contents of > /usr/lib/arm-linux-gnueabihf/ from > http://ftp.us.debian.org/debian/pool/main/b/boost1.62/libboost-python1.62.0_1.62.0+dfsg-4_armhf.deb > > and > http://ftp.us.debian.org/debian/pool/main/b/boost1.62/libboost-python1.62-dev_1.62.0+dfsg-4_armhf.deb > > > I'm pretty sure I have a working armhf build -- I haven't had a chance to > run it on target yet because I need to figure out how to package it > (currently still in the RIP environment). > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to machi...@googlegroups.com <javascript:><mailto: > machinekit+unsubscr...@googlegroups.com <javascript:>>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to machi...@googlegroups.com <javascript:><mailto: > machinekit+unsubscr...@googlegroups.com <javascript:>>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
