[apparmor] [patch] fix libapparmor ruby bindings for ruby 2.0

Christian Boltz apparmor at cboltz.de
Wed Jun 12 22:25:23 UTC 2013


Am Mittwoch, 12. Juni 2013 schrieb John Johansen:
> On 06/05/2013 01:23 PM, Christian Boltz wrote:
> > you might have noticed the discussion about the libapparmor ruby
> > bindings build failures on openSUSE Factory, which is the first
> > version with ruby 2.0.
> > 
> > The problem was that DESTDIR was added to too many variables, which
> > finally resulted in
> NAK, at least until I understand what is going on better. Specifically
> from the referenced bug we have
>   The error message is:

> *** No rule to make target
> `/home/abuild/rpmbuild/BUILDROOT/apparmor-2.8.1-147.1.x86_64/usr/incl
> ude/ruby-2.0.0/ruby.h', needed by `LibAppArmor_wrap.o'.  Stop.
>   The bug is that it searches for ruby.h _inside the buildroot_, which
> is obviously wrong.

    [end of quoting from the bugreport, and sorry for the linebreaks - 
    KMail doesn't handle quoting of logs very well ;-) ]

To make things clear: ruby.h is part of the ruby-devel package.

Also note that the quoted error message is from the openSUSE build 
service, which means a fresh virtual machine for each build job. 
(No chroot etc. involved.)

> But when building packages searching the build root is the correct
> place to search as you may be building against a different version
> than your system has installed.

Well, we have up to 3 places:
1) the running system
2) a chroot that is used for building (with only the packages needed for 
   build installed)
3) DESTDIR as target for "make install" - in other words: everything 
   that will end up in the RPM/DEB package

1) is needed for obvious reasons ;-)

2) is optional, and not too different from 1) - from the compiler's POV, 
a chroot looks like the running system. The only difference is that with 
a chroot you can be quite sure not to break your system ;-) and you can 
control the list of installed packages easier.
Instead of a chroot (as used by the openSUSE "build" script), you can 
also setup a virtual machine for each build (as done by the openSUSE 
build service)

3) is highly recommended because otherwise you could easily break your 
system with make install, and you would never know exactly if you found 
all files you need to package.

> Some googling around using
>   extconf.rb header file ruby.h
> I find that this error happens usually because of missing the ruby-dev
> packages

I have a BuildRequires: ruby-devel of course ;-)

> My guess is we need to add a dependency on a missing ruby-dev or
> similar package so that we can pull the ruby.h into the build root.

It looks like you confuse the build root (2) with DESTDIR (3).

ruby-devel installs ruby.h in the build root (which can be 1) or 2) - 
but the (with Ruby 2.0) generated Makefile.rb searches for it inside
3) DESTDIR, which is just wrong. (Remember: DESTDIR contains what will 
end up in the RPM/DEB package.)

The patch fixes this problem, but as I already said, I'm not sure if 
it's the best way to fix it. I'm not even sure if it's a bug in our 
extconf.rb, in swig or if mkmf from Ruby 2.0 is buggy ;-)


Christian Boltz
Tja, und so hab ich wohl die beiden wichtigsten Dinge gelernt, die man
IMO ueber Linux lernen kann: Wie man Doku findet, liest, verarbeitet und
versteht :) Und Geduld (v.a. mit sich selbst) bzw. Durchhaltevermoegen..
[David Haller in suse-linux über seine ersten Erfahrungen mit Linux]

More information about the AppArmor mailing list