Cross Dressing Architecture: Which CPU Do I Wear?

I’m going to make this a quick post because it’s late and I am just trying to get something done… I’m cross compiling a kernel for a small device. The problem is that my work station is an i7 running 64 bit Gentoo. The target is a Via C7 and while I could probably do everything in 64 bit on the device I don’t necessarily want to double my memory register widths on a device that is cramped for memory. Gentoo has an awesome tool called crossdev that automatically built the toolchain for my target device.

The problem now is that I can’t fool make. It knows something is wrong with what I am doing. I even decided to

chroot in to a i686 only environment Make still freaked out that I was being crazy trying to compile code. The error was, “CPU you selected does not support x86-64 instruction set”! I’ve

searched around the internet and no one had

an immediate solution. Of course… I got to thinking… I’ll alter the Makefile to set the arch… changed some uname -m to echo i686’s here some ARCH=${ARCH} to ARCH=i686’s there… Still it wouldn’t compile! Even -m32 didn’t work. Make knew something was up and I realized that the make binary was doing

this check.

The solution was really simple… It’s something I did long ago to compile a 32bit kernel. Most distros ship with arch and setarch. The arch command tells you what you’re running. The setarch command sets your arch to anything you want! I want i686! Everything compiled

great after and we all had tea and scones.

Truncate: Your Proble

I had a really stupid problem. I needed to truncate a file in place and my distribution didn’t provide this. At least it didn’t provide this when the system was created. I’m using Gentoo and the machine I am working on was put in place almost five years ago.

The nitty gritty is that we’re using Bacula as our backup solution. Occasionally Bacula stops responding and we have to restart the service. When this happens any backup that wasn’t completed and committed to the catalogue results in a corrupted volume. Our volumes are file based and are a couple hundred gigabytes. The solution I came up with so long ago was to simply dd the amount of data the catalogue thought the volume should be and copy it back over the source. Kind of like traveling back through time to a place where the backup software was happy. The problem with this method is that the we end up copying basically most of the data, minus the amount of data added from the incomplete backup, and then copying it back again. The system must then guarantee that the maximum size of the volume must be available for the copy, ie there must always be a couple hundred gigs free to complete this repair.

The best solution would be to truncate the file in place. A proper truncate command shouldn’t have to copy any parts of the file and simply inform the file system that the file ends abruptly at x bytes and be relatively instant vs io intensive. The good guys at the Gentoo forums recommend back in 2005… to simply compile the FreeBSD version. That probably resolved everyone’s problems or confused people who don’t know how to simply compile files. The problem I have is that now I have a rogue executable on the machine in the system’s bin directory or whatever the heck I will end up putting it. You can’t really trust a systems admin with corners. Therefore I created an ebuild for this file so that I could put it in the package management system on Gentoo, called Portage. If a systems administrator who is not me needs to figure out where the file came from our where the packages files are located they can now use the Portage system to figure this information out.

The newest version of coreutils just has this included. I didn’t know that until after I tried to install my new ebuild on a system with a more recent update of Gentoo. Because this is an ugly hack since the correct answer is to

just update the software on the machine I didn’t go back and grab a GNU version of truncate. The provides an answer to my problem but maybe someone else’s.

If you’re not running Gentoo then you can follow my easy simple compiling directions.

1. Grab the source from FreeBSD or here
2. Copy it to your *inx system that doesn’t ship with truncate
3. Run the command gcc -o truncate truncate-9999.c (if you’re using something other than gcc you could try replacing the gcc command with your c compiling, e.g. gcc, cc, icc…
4. Test truncate out to make sure that the BSD c library isn’t too divergent from the GNU library or whatever c library you compiled for

If you’re running Gentoo then just create an over lay with my ebuild from here.

Diablo 3: Keeping Your Work

Ok… so… you bought Diablo 3, you are running Gentoo, the files aren’t updating… The installer isn’t working… The launcher isn’t working either… Sure you can copy the files from your Windows computer, if you have one, but every time there is a patch you’d

need to do this.

This was the problem I was facing. Fortunately there are some really cool people on the internet who have written patches for Wine to over come these issues and Wine almost fully supports Diablo 3 right out of the box. Now it’s just our job to apply these patches. The problem is the pesky ebuild files. We want to apply 4 patch files to make this work. If we just compile from source, then portage is going to think we didn’t install here.

Here is what I did to accomplish getting Diablo 3 installed and running on Gentoo. All of my steps are adapted from the WineHQ entry for Diablo 3. The patches are provided by third parties whom I don’t know and not affiliated.

Step one) Diablo 3 required some Microsoft C++ package. There is a really awesome program called winetricks that will install a plethora of Wine related items. You have to unmask the package in portage and emerge winetricks first.

• winetricks vcrun2008

Step two) I didn’t want to mess with creating an ebuild or installing Wine from source. To do this, I added the keepwork feature in /etc/make.conf. Afterward I started the Wine emerge and control-C’ed the install just after it started to configure the source. With keepwork there, all I had to do was go to the work directory of Wine

to proceed to the next step. The work directory will be in the output of the emerge.

Step three) The patches are listed at the end of the this thread. They are the works of other people and they are third party patches to Wine. Wine has not yet accepted or declined them in to the source tree. They are obviously at your own risk. The first three patch

files are part of a greater patch. I also synlinked the wine-1.5.4 directory to b so I could copy and paste the file paths. There is likely a better way to do this, but I was just wanting the job done. After the first three files are patched, you just run the make_requests script in the tools folder to update the server source. The first patch (three patch files) addresses the inability to install or update Diablo. The second patch addresses the game crashing when altering the video settings.

• patch < 86263.txt
• patch < 86264.txt
• patch < 86265.txt
• ./tools/make_requests
• patch < reset.patch

Step four) Emerge Wine as you normally would. The keepwork feature will not overwrite your work directory and install Wine the usual Gentoo way. Obviously you want to disable this feature as it’s horrible and should never be used. I don’t really condone using this feature, but until a permanent solution is found, this should do the trick.