Bugzilla Bug 232775

Hello,

I had it with vmware... Every time after kernel upgrade need to wait for new
modules.
Also done waiting for qemu to support gcc-4.

So checked out virtualbox. But found that a lot of the build process is using
binaries... Not in the Gentoo way.

So I invested some time and made this compile from source.

Added kBuild ebuild to build from source.
Minor modifications for the virtualbox ebuild, especially use the system yasm
and not pre-built one.

I hope you find this handy.
I think that a snapshot of kBuild can be provided on mirrors for now.

Now it is truly open-source!

Alon.

Created an attachment (id=161206) [edit]
kBuild-9999.ebuild

This is the kBuild system that is provided in binary form via the VirtualBox
tarball.
The ebuild compiles the kBuild from source using boostrap.

Created an attachment (id=161208) [edit]
virtualbox-1.6.2.ebuild.diff

Hello jokey, swapon,
Is there anything I can do in order to make this better?
Thanks!

(In reply to comment #3)
> Hello jokey, swapon,
> Is there anything I can do in order to make this better?
> Thanks!
> 
hi Alon,

yes we know that the build system used by VirtualBox[1]
is shipped as a binary. it's also true that gentoo prefers
to build everything, if/when is possible, from the sources,
but it's not clear (to me) what are the benefits in building the 
kBuild system from sources.

At the moment if i'm not wrong, this build framework it's only used
by VirtualBox, and it is still opensource when shipped in a binary form
(kBuild is GPL-2).

Keep in mind that this is all _imho.

@Jokey: we are interested in your opinion :)

[1] http://www.virtualbox.org/wiki/kBuild

Hi!

Thank you for your response.

I don't like binaries to be run on my system... As it is very difficult to
verify that they are doing what they claim to do.
Also, it is more difficult to filter these files.

The kBuild is in DEPEND not RDEPEND, so it can safely be cleaned from system
after build... It is cleaner to have it as a separate package.

If you don't like kBuild build to be a separate package, I can modify the
virtualbox ebuild to build the kBuild as first stage.

I just think that many users prefer that no alien binaries be executed on their
systems... And until this case I did not know any exception.

Jokey, I appreciate your view?
I could not find any other GPL-2 package that is used in binary form (all or
partial) in portage tree.

We can do it that way, no problem on my end.

Alessio, just add the changed ebuilds to my overlay so I can commit them ;)

(In reply to comment #7)
> We can do it that way, no problem on my end.
> 
> Alessio, just add the changed ebuilds to my overlay so I can commit them ;)

Well, yesterday (Sep 2, 2008) 1.6.6 was released, and starting from this
release we get rid of binaries shipped with it (kbuild, yasm).

So i created an ebuild for dev-util/kbuild[1], it's not a live ebuild since a
stable released exists (0.1.3), the ebuild build kbuild starting from
bootstrap, to totally avoid the use of binaries (as Alon suggested in
its'ebuild).

The yasm release used is 0.6.2 (currently stable) and known to work fine[2]
with virtualbox starting with 1.6.0 release.

This is the list of the ebuilds forced to not use the shipped binaries:
-app-emulation/virtualbox-ose-1.6.6
-app-emulation/virtualbox-guest-additions-1.6.6
-x11-drivers/xf86-input-virtualbox-1.6.6
-x11-drivers/xf86-video-virtualbox-1.6.6

Currently they are hosted on jokeys' overlay[3]
[1] http://svn.netlabs.org/kbuild/wiki
[2] http://www.virtualbox.org/ticket/1079 (last comment)
[2] http://overlays.gentoo.org/svn/dev/jokey/

Great!

A few notes about the kbuild ebuild:

1. In gentoo you need to use the autotools eclass for auto stuff, please refer
to attachment#161206 [edit] for example. Notice the eautoreconf at the unpack stage
and the AUTORECONF=true at the build stage.

2. You should never depend on a specific version of automake. Your build should
work with latest stable automake, but if you require a specific automake
version (which you shouldn't as you need to fix your implementation), then add
WANT_AUTOMAKE="version" before the inherit autotools.

---

If I understand correctly the 1.6.6 version should work with gcc-4.3.1, can you
please confirm and remove restriction?

Alon.

(In reply to comment #9)
> 1. In gentoo you need to use the autotools eclass for auto stuff, please refer
> to attachment#161206 [edit] [edit] for example. Notice the eautoreconf at the unpack stage
> and the AUTORECONF=true at the build stage.
The bootstrap procedure already calls autoreconf for /src/kmk and /src/sed
so there is no benefit if we call it twice.

> 2. You should never depend on a specific version of automake. Your build should
> work with latest stable automake, but if you require a specific automake
> version (which you shouldn't as you need to fix your implementation), then add
> WANT_AUTOMAKE="version" before the inherit autotools.
right, fixed it, i can confirm that with this release of kbuild we need
automake 1.9.

> If I understand correctly the 1.6.6 version should work with gcc-4.3.1, can you
> please confirm and remove restriction?
This is what the changelog reports i hope that it's really fixed, 
currently i'm testing virtualbox with gcc-4.3.1, i will remove the restriction
if successfull.

(In reply to comment #9)
[..]
> 
> If I understand correctly the 1.6.6 version should work with gcc-4.3.1, can you
> please confirm and remove restriction?

Tests done, 
unluckily the fix shipped with virtualbox-ose-1.6.6 it's only a workaround t
hat allows users to pass the version of a "compatibility compiler" (< 4.3.x)
and build the Qemu recompiler parts with it (instead to compile it with gcc
4.3.x) on distros that have a gcc-compat package.

We don't have a gcc-compat package and force an user to build an older
gcc is overkill, this fix can be useful only if the users have at least 2
version installed, but in that case gcc-config will do the trick.

(In reply to comment #10)
> (In reply to comment #9)
> > 1. In gentoo you need to use the autotools eclass for auto stuff, please refer
> > to attachment#161206 [edit] [edit] [edit] for example. Notice the eautoreconf at the unpack stage
> > and the AUTORECONF=true at the build stage.
> The bootstrap procedure already calls autoreconf for /src/kmk and /src/sed
> so there is no benefit if we call it twice.

It won't happen twice. This why AUTORECONF=true at compile stage... It just
will call true during build.
In Gentoo you cannot call autoreconf directly as it won't use the tools version
you want.

(In reply to comment #11)
> (In reply to comment #9)
> [..]
> > 
> > If I understand correctly the 1.6.6 version should work with gcc-4.3.1, can you
> > please confirm and remove restriction?
> 
> Tests done, 
> unluckily the fix shipped with virtualbox-ose-1.6.6 it's only a workaround t
> hat allows users to pass the version of a "compatibility compiler" (< 4.3.x)
> and build the Qemu recompiler parts with it (instead to compile it with gcc
> 4.3.x) on distros that have a gcc-compat package.
> 
> We don't have a gcc-compat package and force an user to build an older
> gcc is overkill, this fix can be useful only if the users have at least 2
> version installed, but in that case gcc-config will do the trick.
> 
hello , 

can you add the fix patch on the overlay ebuild and activate it with an use
param since gcc4.3 is not stable , most of people have at least gcc4.3 and an
previous gcc version.
the gcc-config is great but when it is truly an hassle when you do an emerge
world or something equal

thank

We have a version in tree now depping on that thing

But you did not add the usage of autotools eclass, the result is execution of
autoreconf by the package itself which is wrong as far as I know.

You need to use eautoreconf in the needed directories and disable the build to
to it by itself (AUTORECONF=true).

Hi, I just tried installing virtualbox-ose and ended up with emerge telling me
to use a version of gcc lower than 4.3 and dieing.

This is clearly a non-solution "solution", because, what do I do now? ;)
- Install an old gcc? This would be no different than adding a dependency on an
old gcc (slot).
- Not install virtualbox? But the point was that I wanted to install it. And
this would be the same thing as masking virtualbox.

I do not know where the actual bug is in, but that package should be masked...
you know... for being buggy and not fit for its job. :) Even if it's god the
almighty gcc 4.3. ;)

And as a temporary solution I see it like this:
- Either the user wants virtualbox. Then he wants it to be installed. Which
unfortunately does require gcc <4.3 for now. If that is too heavy for me, I can
still say no when I see it in  "emerge -atv virtualbox-ose".
- Or the user does not want virtualbox. Then his opinion is not related to this
anyway.

Right now we get portage telling us: "Ok, I told you I can emerge
virtualbox-ose, you told me to do it, but I failed and didn't, because I knew
from the beginning that I could not..."
Under humans you'd call that a deliberate lie, which is far from nice behavior.
:)

It is hard to love Gentoo, when it lies to you and seems to hate you. I'm not
the type for that kind of masochistic relationship. ;)

(In reply to comment #16)
replied to this comment in bug #226495