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 attachment 161206 [details] 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 attachment 161208 [details, diff] 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 [details] 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 [details] [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 [details] [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
