You need to construct additional pylons. Building wine for #FreeBSD

I’ve been playing Blizzards’s Starcraft 2 on Linux via wine emulation lately and thought I’d see if I can get the same thing working on FreeBSD via the emulators/i386-wine-devel port.  After talking with the fine folks in #bsdports on EFNet, I finally found a recipe that is poudriere friendly and seems to spit out something that sort of works.

David Naylor ( has a working method for constructing wine on FreeBSD and this should work in most cases for using current.  The method is really designed for building a binary package for releases, most folks wouldn’t want to go down this route.

In order to begin, get poudriere configured and ready to go.  You’ll need to construct an i386 jail for the first part of this process.  Something like I show in my poudiere blog post

poudriere jail -c -j 11i386 -v head -a i386 -m svn

This will give you a build environment to get the 32bit binaries for wine built and packaged up for step 2.

poudriere builk -j 11i386 emulators/i386-wine-devel

If all goes well, you now have an i386 package of wine that will be consumed as a distfile for the amd64 package build.  I redefine PORTSDIR=/usr/local/poudriere/ports/default in /etc/make.conf.

If you are like me and use poudriere for everything, copy it to /usr/local/poudriere/ports/defaults/distfiles/freebsd:11:x86:64/

Now you’ll need to edit the emulators/i386-wine-devel distfile with the appropriate information generated from a sha256 and ls -l of your packagefile in your local i386 repo:

sha256 i386-wine-devel-1.7.7,1.txz

SHA256 (i386-wine-devel-1.7.7,1.txz) = 8d0073d1c10be9afbe7c3c9874a31ac110c1f96cf6ddcda74ca16d31bad55d1b

Modify this with the following to make it compatible with your system:

SHA256 (freebsd:11:x86:64/i386-wine-devel-1.7.7,1.txz) = 8d0073d1c10be9afbe7c3c9874a31ac110c1f96cf6ddcda74ca16d31bad55d1b

Modify the to exclude checks for the OS version:

—    (revision 335346)
+++    (working copy)
@@ -41,10 +41,10 @@

.include <>

-.if !(${OSVERSION} >= 803000 && ${OSVERSION} < 900000) && !(${OSVERSION} >= 901000 && ${OSVERSION} < 1000000)
-IGNORE=        binaries compiled for FreeBSD 8.3+ and 9.1+ only
+#.if !(${OSVERSION} >= 803000 && ${OSVERSION} < 900000) && !(${OSVERSION} >= 901000 && ${OSVERSION} < 1000000)
+#IGNORE=        binaries compiled for FreeBSD 8.3+ and 9.1+ only

RUN_DEPENDS+=   ${DATADIR}/gecko/wine_gecko-2.24-x86.msi:${PORTSDIR}/emulators/wine-gecko-devel

And now, you can try building the package in your *AMD64* poudriere build with:

poudriere bulk -j 11amd64 emulators/i386-wine-devel

If my instructions have succeeded, you now have a package suitable for installation on your amd64 machine that will now let you do wine things.

Now, I need to figure out what the Blizzard Network Installer is trying to do as it runs, self-updates and hangs.

Moving forward by going slightly backwards and to the right, UEFI booting on #FreeBSD

The FreeBSD Foundation has been working towards the future of booting in x86 and catching up to our friends in Linux-land by sponsoring work on a UEFI enabled boot loader.  This work was taken on by Benno Rice ( and Ed Maste (

So far, it appears that one can indeed boot FreeBSD as I will demonstrate on my Thinkpad T520.

Starting with the UEFI project branch, one must build a 64bit version of libstand in tree.

cd uefi/lib/libstand && make

Modify the makefile in sys/boot/amd64

Index: amd64/efi/Makefile
— amd64/efi/Makefile    (revision 258775)
+++ amd64/efi/Makefile    (working copy)
@@ -77,8 +77,8 @@
LIBEFI=        ${.OBJDIR}/../../efi/libefi/libefi.a
CFLAGS+=    -I${.CURDIR}/../../common

+DPADD=        ${LIBFICL} ${LIBEFI} ../../../../lib/libstand/libstand.a
+LDADD=        ${LIBFICL} ${LIBEFI} ../../../../lib/libstand/libstand.a

.include <>

Now you can build loader.efi and get it to link against the 64bit version of libstand:

cd sys/boot && make

UEFI will look for a FAT formatted partition with the “efi” signature on it.  FreeBSD’s gpart can create this partition for you, so do the following foo:

gpart create -s gpt da0

gpart add -t efi da0

gpart add -t freebsd-ufs da0

$ gpart show da0
=>     34  2013117  da0  GPT  (983M)
34   131072    1  efi  (64M)
131106  1882045    2  freebsd-ufs  (919M)

newfs -t msdosfs /dev/da0p1

newfs /dev/da0p2

Mount the fat formatted partition, create the EFI directory structure(this is mandatory) and copy the loader.efi binary into place as bootx64.efi

mount -t msdosfs /dev/da0p1 /mnt

mkdir -p /mnt/efi/boot

cp uefi/sys/boot/amd64

Because the kernel currently needs to be aware of the new style UEFI memory map, you can’t run stock -current in this configuration.  You’ll need to use a kernel from the projects/uefi branch when constructing your bootable device.  I used a 1G usb thumbdrive for this test, so mount the UFS partition and use it as a DESTDIR for your installworld/installkernel:

make -s buildworld

make -s buildkernel

mount /dev/da0p2 /mnt

DESTDIR=/mnt make -s installworld

DESTDIR=/mnt make -s installkernel

DESTDIR=/mnt make -s distribution

Setup an /etc/fstab on this stick:

/dev/da0p2             /               ufs     rw,              1       1

At this point, your USB disk is ready for its first booting attempt.



I have to toggle UEFI/Legacy BIOS mode in my laptop.  For your entertainment, here it is.  This has the convient side effect of not booting from my other disk devices in my laptop as they do not have the “proper” fat formatted EFI partition on them.  This actually yeilds a pretty quick boot to the loader.

Amazing!  It did!  Sort of.

Now we have the entertainment of trying to figure out how to get here to multiuser.





With a “show” we find out that the loader has selected the EFI partition “part6” as the boot device.  “lsdev” shows us all the partitions that we could boot from, but I have chosen well in this example and can easily see that the one I really want is tagged with a “(removable)”.

In this case executing a “set currdev=part7” sets up the loader to boot and executing “boot” will get this system into multiuser.

Many thanks to the folks at the FreeBSD Foundation for these initial steps into UEFI.  The project branch in subversion is publicly available and I highly encourage folks to engage the community to get this closer to production grade.