I'm trying to set up a cross-platform development environment to develop software on a i386 which is to run on an ARM (Beaglebone Black). In an earlier thread,viewtopic.php?f=8&t=131337stevepusser suggested looking into qemu and doing it in a virtual machine, which is a good idea -- simple and elegant, if a little heavy-handed.

But I am having trouble installing libgtk-3-dev due to unmet dependencies. To be clear, there is a chroot directory, set up with debootstrap to use the armhf architecture. I was able to install CodeBlocks there, and it works fine. It's slow due to the emulation, but it works.

However, I also need wxWidgets, which requiresapt-get install libgtk-3-devwhich gives

The following packages have unmet dependencies:libgtk-3-dev : Depends: libglib2.0-dev (>= 2.41.2) but it is not going to be installed Depends: libgdk-pixbuf2.0-dev (>= 2.27.1) but it is not going to be installed Depends: libpango1.0-dev (>= 1.36.7) but it is not going to be installed Depends: libatk1.0-dev (>= 2.7.5) but it is not going to be installed Depends: libatk-bridge2.0-dev but it is not going to be installed Depends: libcairo2-dev (>= 1.10.0) but it is not going to be installed

Based on what has worked before I tried to force the issue withapt-get install libglib2.0-devbut got

The following packages have unmet dependencies: libglib2.0-dev : Depends: libglib2.0-0 (= 2.42.1-1+b1) but 2.48.0-1~bpo8+1 is to be installed Depends: libglib2.0-bin (= 2.42.1-1+b1) but it is not going to be installed

When I've used that method to cross compile, the virtual machines are bare-bones skeletons of a Debian install. I've started with debianized source files that I know will build into a deb package successfully on my own machine. What a package needs to build is listed in the debian/control file, and pbuilder will read that and automatically install what's listed before starting the build. Debian "essential" packages such as build-essentials need not be listed.

So if you need libwxgtk3-dev to build your package, listing that in the build-depends will have pbuilder automatically get everything that that package depends on. Pbuilder is going to build the package, not code:blocks.

The openSUSE build service also advertises support for Debian armhf builds, but you have to send them an email to enable anything other than i386 and amd64 architectures. I've never had the need to do that, but have a variety of repos in there for various i386/amd64 packages.

Thanks. What you are trying to tell me is begining to sink in. I think I now see the role that pbuilder plays. If all of the installs had gone well -- as they did on my normal i386 toolchain -- then I wouldn't need pbuilder. But it should allow me to build these problematic packages from source with less fuss than it would otherwise entail.

Yes, pbuilder, like the openSUSE build service, depends on the package already being "debianized", which is to have a /debian folder added into the source folder with various files that specify what section it goes into and configuration and build procedures.

You can get source files for existing packages at packages.debian.org and run them through your pbuilder QEMU setup to get a sense of how it works. Then your own program can be debianized, which is generally pretty easy if it has a standard build setup, such as the GNU autotools, CMake, Qt, or others. Otherwise you'll have to specify the build and install commands as overrides in the debian/rules file. I can help if you have questions.

I've run into an error that I can't make sense of -- pdebuild givesE: Cannot find ./debian file

Here's what was done leading up to the error. Recall that the goal is to rebuild a package, using my i386 jessie machine, so that it will run on an armhf machine (Beaglebone Black). In particular, I need libgtk-3-dev for armhf, and this package seems to have some problem.

I copied the .pbuilderrc file given by Jodal on his website athttps://jodal.no/2015/03/08/building-ar ... -pbuilder/I did change every instance of 'wheezy' to 'jessie', and added lines to echo the values of the different variables to stdout, but made no other changes. Nor have I changed the default pbuilder files in /etc.

ThenOS=debian DIST=jessie ARCH=armhf pbuilder --create --debugseems to work fine. I did add the --debug flag for more verbose output to help understand what's happening, but that shouldn't matter (?). There's now /var/cache/pbuilder, which contains an empty build directory, debian-jessie-armhf-base.tgz and debian-jessie-armhf/aptcache, which contains a bunch of .deb files.

What is this ./debian directory?It may be relevant that I did not do any of the things Jodal describes with the keyring. He's doing something more sophisticated than I am, and it didn't seem necessary.

Also, am I correct in thinking that, once pdebuilder does its magic, there will be a set of compiled libraries, executables, and anything else in the package in BUILDRESULT? (Or maybe it's a .deb file). Either way, it should give something appropriate to run and/or install on an armhf machine?

My (stupid) mistake was that you need to cd into the directory with the actual code; it's not good enough to run pdebuild in the location where you did the apt-get.

Anyway, this results in several files found in /var/cache/pbuilder/debian-jessie-armhf/result (this location is specified by Jodal's .pbuilderrc file). Among these files is bc_1.06.95-9_armhf.deb. Copy that deb file to the BBBchroot directory, created earlier with debootstrap and qemu. Then do

chroot BBBchrootcd /pbtestdpkg -i *.deb

where pbtest is the location of the bc deb file created by pdebuild.

So we have proof of concept. The bc command now exists on the armhf machine being emulated on the i386. But I still can't figure out how to rebuild libgtk-3-dev for armhf. Following the template of what worked for bc, I did:

The gist of which is that there are unmet dependencies and pdebuild doesn't know how to deal with them.

Based on small crumbs I found with google, it seems like there is some way to have pdebuild work up the tree to build whatever is necessary for the ultimate target, but it's unclear how this is arranged. Does it involve any of mk-build-deps, gdebi, or something related to the HOOKDIR value set by the .pbuilderrc file?

Actually, step back and consider the actual goal: compiling code which relies on libgtk-3-dev so that it will run on BBB. Maybe I don't need pbuilder at all. pbuilder would be an automated way to convert my code to run on a variety of architectures and OSes, but I only want to run on a single physical BBB -- the one on my desk right now. Would it work to chroot to the armhf emulator, apt-get the gtk source, like I already did, examine the contents of debian/control (which seems to list all of the prerequisite packages), apt-get install any missing packages, then do a configure, make, and make install of gtk, all within the armhf emulator? Granted, that is seen as a crude hack these days, and pbuilder is pretty cool, and having come this far I want to understand it better, but maybe what I just described is an easier and more direct route to the goal -- if it would work.

So once your package has source files "debianized", simply listing libgtk-3-dev as a build-depend in the debian/control file will have pdebuild get and install the armhf version, plus whatever other build-depends are listed, in the QEMU VM, before the rest of the build commands are executed.

I feel like you keep bringing me to the water, and I don't even see that there's water there for me to drink. I apologize for that.

Let me see if I understand what you're proposing. Write and build the code however I normally would using my usual toolchain. When I want to run it on BBB, there is a way to debianize the code (however that is done), and I would then run this debianized code through pbuilder/pdebuilder and out the other end of this machine would come a deb file which I could copy to BBB and install with dpkg -i. That would work (or I take your word for it that it would), but I was hoping for something more interactive. If I want to test the code as it is developed, then I will have to run it through pbuilder each time, and that is slow.

Maybe the above really is easiest, but what I was hoping to do is set up a chroot with qemu emulating the armhf. That I have done. The problem is installing libgtk-3-dev on this emulated machine. I was trying to install it by compiling from source since apt-get install does not work due to circular dependencies, and I thought that pbuilder/pdebuilder might be a way to do that compilation. Once all the libraries are installed, I could work within this emulated machine in exactly the same way I do on a "normal" machine. It would compile my source, and I could then copy it over to BBB where it would run -- perhaps after I install a bunch of third-party libraries there too.

So, the reason I was trying to compile libgtk-3-dev in armhf format is because it wouldn't install on the emulated armhf machine. It does install on the BBB, but not in my chroot/qemu emulator for some reason.

If I can, it would be great to set this up both ways: the way I was thinking, which does not involve pbuilder; and as you describe, with pbuilder. Each way would teach me something about debian.

That makes sense (about backports) since I installed codeblocks before attempting to install libgtk-3-dev. As I recall, CB is only available as a backport if you're running jessie. That is, CB was installed withapt-get -t jessie-backports install codeblocksAt least, I assume that's the cause since nothing else was ever installed.

I'll try starting over, and installing codeblocks last instead of first. Even if that works, I do want to understand how to debianize my code and use pbuilder (once that code is written).