Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Unresolved libgtk-3-dev dependencies with Qemu/armhf

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Unresolved libgtk-3-dev dependencies with Qemu/armhf

#1 Post by rsfairman »

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,
http://forums.debian.net/viewtopic.php?f=8&t=131337
stevepusser 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 requires
apt-get install libgtk-3-dev
which gives

Code: Select all

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 with
apt-get install libglib2.0-dev
but got

Code: Select all

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
So...try
apt-get install libglib2.0-0
and get
libglib2.0-0 is already the newest version.
And then
apt-get install libglib2.0-bin
gives

Code: Select all

The following packages have unmet dependencies:
 libglib2.0-bin : Depends: libglib2.0-0 (= 2.42.1-1+b1) but 2.48.0-1~bpo8+1 is to be installed
So it's circular. How to get out of this?

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#2 Post by stevepusser »

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.
MX Linux packager and developer

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#3 Post by rsfairman »

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.

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#4 Post by stevepusser »

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.
MX Linux packager and developer

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#5 Post by rsfairman »

I've been pulled into other things for the past day or two, but I'm focusing on this now, and starting to figure out pbuilder. Thanks for the offer of further help and advice. I may need it...

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#6 Post by rsfairman »

I've run into an error that I can't make sense of -- pdebuild gives
E: 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 at
https://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.

Then
OS=debian DIST=jessie ARCH=armhf pbuilder --create --debug
seems 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.

As a first test of pdebuild, I tried a small simple package -- the 'bc' tool (a small command-line calculator) . So
mdkir ptest
cd ptest
apt-get source bc
OS=debian DIST=jessie ARCH=armhf pdebuilder
which immediately returns
E: Cannot find ./debian dir

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?

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#7 Post by rsfairman »

Wait...I am hot on the trail. Don't bother posting an answer to the previous when the question has a trivial solution. I'll post a followup once I'm sure everything works as it should.

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#8 Post by rsfairman »

I've made some progress, but not as much as I thought I would. Jodal omitted a critical step, which is so obvious I can't blame him. The steps given above should have been.

mdkir ptest
cd ptest
apt-get source bc
cd bc-1.06.95
OS=debian DIST=jessie ARCH=armhf pdebuild

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 BBBchroot
cd /pbtest
dpkg -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:

mkdir /gtk_build_test
cd /gtk_build_test
apt-get source libgtk-3-dev
cd gtk+3.0-3.14.5
OS=debian DIST=jessie ARCH=armhf pdebuild

The apt-get source does complain a little, saying that it is "Picking gtk+3.0 as source package instead of 'libgtk-3-dev'," but I don't think that matters. The pdebuild gives this output

Code: Select all

root@debian:/pb_gtkbuild/gtk+3.0-3.14.5# OS=debian DIST=jessie ARCH=armhf pdebuild
Using Jodal's script
DEBOOTSTRAPOPTS set to --variant=buildd
BASETGZ set to /var/cache/pbuilder/debian-jessie-armhf-base.tgz
BUILDPLACE set to/var/cache/pbuilder/build
BUILDRESULT set to/var/cache/pbuilder/debian-jessie-armhf/result/
CCACHEDIR set to
APTCACHE set to/var/cache/pbuilder/debian-jessie-armhf/aptcache/
LOGFILE set to
dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>= 0.4.93) gnome-pkg-tools (>= 0.11) gtk-doc-tools (>= 1.20) dh-autoreconf autotools-dev libxt-dev libxkbfile-dev libcups2-dev (>= 1.2) libcolord-dev (>= 0.1.9) librest-dev libjson-glib-dev gobject-introspection (>= 1.41.3) libgirepository1.0-dev (>= 1.39.0) xvfb
W: Unmet build-dependency in source
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: source package gtk+3.0
dpkg-buildpackage: source version 3.14.5-1+deb8u1
dpkg-buildpackage: source distribution jessie
dpkg-buildpackage: source changed by Andreas Henriksson <andreas@fatal.se>
 dpkg-source --before-build gtk+3.0-3.14.5
dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>= 0.4.93) gnome-pkg-tools (>= 0.11) gtk-doc-tools (>= 1.20) dh-autoreconf autotools-dev libxt-dev libxkbfile-dev libcups2-dev (>= 1.2) libcolord-dev (>= 0.1.9) librest-dev libjson-glib-dev gobject-introspection (>= 1.41.3) libgirepository1.0-dev (>= 1.39.0) xvfb
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
dpkg-buildpackage: warning: this is currently a non-fatal warning with -S, but will probably become fatal in the future
 fakeroot debian/rules clean
debian/rules:8: /usr/share/cdbs/1/rules/autoreconf.mk: No such file or directory
debian/rules:9: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory
debian/rules:10: /usr/share/cdbs/1/rules/utils.mk: No such file or directory
debian/rules:11: /usr/share/cdbs/1/class/gnome.mk: No such file or directory
debian/rules:12: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
debian/rules:13: /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk: No such file or directory
debian/rules:14: /usr/share/gnome-pkg-tools/1/rules/gnome-version.mk: No such file or directory
make: *** No rule to make target '/usr/share/gnome-pkg-tools/1/rules/gnome-version.mk'.  Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
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.

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#9 Post by stevepusser »

Debian already provides libgtk-3-dev in armhf format, no need to rebuild it: https://packages.debian.org/search?keyw ... ection=all

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.
MX Linux packager and developer

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#10 Post by rsfairman »

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.

User avatar
fireExit
Posts: 559
Joined: 2014-11-20 11:22

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#11 Post by fireExit »

rsfairman wrote:

Code: Select all

The following packages have unmet dependencies:
 libglib2.0-bin : Depends: libglib2.0-0 (= 2.42.1-1+b1) but 2.48.0-1~bpo8+1 is to be installed
So it's circular. How to get out of this?
you have packages (at least libglib2.0-0) installed from backports, that's why the libgtk-3-dev dependency chain is broken.

rsfairman
Posts: 20
Joined: 2017-01-18 22:16

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#12 Post by rsfairman »

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 with
apt-get -t jessie-backports install codeblocks
At 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).

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Unresolved libgtk-3-dev dependencies with Qemu/armhf

#13 Post by stevepusser »

I would debianize and test-build your project on your native platform first. Once that works correctly, you should be able to use pdebuild to make armhf packages.
MX Linux packager and developer

Post Reply