[PATCH] FTBFS on Debian GNU/kfreebsd

[vincent]

On Debian GNU/kfreebsd, 0 A.D. fails to build from source while building premake (Debian buildd logs can be found at [1]), because premake doesn't recognize Debian GNU/kFreeBSD as a valid BSD platform [2], and thinks we're running a build in a Windows environment instead. The following patch fixes this:

--- a/build/premake/premake4/src/host/premake.h
+++ b/build/premake/premake4/src/host/premake.h
@@ -15,7 +15,7 @@
 #if defined(__linux__)
 #define PLATFORM_LINUX    (1)
 #define PLATFORM_STRING   "linux"
-#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__FreeBSD_kernel__)
 #define PLATFORM_BSD      (1)
 #define PLATFORM_STRING   "bsd"
 #elif defined(__APPLE__) && defined(__MACH__)

---

• [1] ​https://buildd.debian.org/status/package.php?p=0ad
• [2] ​http://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q._How_do_I_detect_kfreebsd_with_preprocessor_directives_in_a_C_program.3F

[vincent]

Sorry about the mess above, I didn't know Trac would butcher my patch like that. Remind me never to post patches in-line again. :/

[fcxSanya]

Replying to vincent:

Sorry about the mess above, I didn't know Trac would butcher my patch like that. Remind me never to post patches in-line again. :/

I fixed formatting a bit :)

[fcxSanya]

About your patch, probably it would be good to ask premake developers to apply it to upstream version, it looks like they applied ​similar patch for DragonFly BSD not so long ago (in December 2011). I don't worked on our build system, but it looks like our premake sources are ​already customised, so it should be ok to apply your patch, but I will leave this to other our guys, who know this better.

[historic_bruno]

Just an FYI, at least the FreeBSD build is not fully functional yet (I don't know about Debian GNU/kFreeBSD) as described ​here. In particular, fcollada fails to build due to missing ​ecvt(), and I think there are additional minor problems on FreeBSD newer than 8.2-stable, see here for details and possible fixes.

Again I don't know how different Debian GNU/kFreeBSD is so you might encounter totally different problems, but thanks for testing :)

[vincent]

Thanks, I'll make a note to myself to forward this patch to upstream premake as well.

On kfreebsd (and with this patch), the build makes it all the way to the linker before dying (ld: cannot find -lexecinfo). Debian has no execinfo package, so I've no idea how to proceed...aside from that, everything else seems to build without a problem.

[historic_bruno]

Replying to vincent:

On kfreebsd (and with this patch), the build makes it all the way to the linker before dying (ld: cannot find -lexecinfo). Debian has no execinfo package, so I've no idea how to proceed...aside from that, everything else seems to build without a problem.

Oh, that was something I added for FreeBSD because it doesn't have ​execinfo in its version of libc. What happens if you comment/remove the relevant lines in premake4.lua (specifically ​784 and ​1186)?

[vincent]

This happens:

Sorry about the low resolution (and for providing a screenshot instead of the actual build log)...I haven't had any success getting Virtualbox's Guest Additions to work yet. :(

[historic_bruno]

(You can use a service like pastebin until you get copy/paste working, it's easier than a screenshot :))

It looks like it's not detecting the BSD sysdep properly, which is entirely possible given the change you had to make to Premake. I think adding the same preprocessor directive (__FreeBSD_kernel__) to the BSD section of ​os.h will do the trick.

[historic_bruno]

Replying to vincent:

Any updates? :) If this works for you, we can make the changes.

[vincent]

Sorry about the delay; I've been a bit busy for the past week and this bug sort of slipped under my radar. :( I'll try to reply a bit more timely next time!

Anyways, I've attached the patches that I used as well as the build log after the corresponding patch is applied (1st patch modifies premake.h, 2nd patch also modifies os.h in addition to premake.h); both builds fail. Now that I've had a chance to take a closer look at those logs outside of a tiny VBox screen, I realize that I was misleading you when I said earlier that the build makes it all the way to the linker before dying...the 2nd log confirms that the build also fails on kfreebsd when building fcollada.

[vincent]

Ok, one step closer now...collada builds but has problems with linking; please see attached buildlog-v3.txt for details.

[vincent]

Finally, everything builds and links properly on kfreebsd with the latest patch I've attached. :)

The part of the patch that modifies premake4.lua probably can't be applied to svn as-is without causing problems for freebsd; premake should treat kfreebsd exactly like freebsd, except on kfreebsd, it needs to link with -ldl and not link with -lexecinfo.

[historic_bruno]

Replying to vincent:

The part of the patch that modifies premake4.lua probably can't be applied to svn as-is without causing problems for freebsd; premake should treat kfreebsd exactly like freebsd, except on kfreebsd, it needs to link with -ldl and not link with -lexecinfo.

That's a bit yucky, I don't suppose Premake's ​os.getversion() would work? If not, maybe we could use uname as a workaround.

[vincent]

$ ./premake4
.../premake4.lua:1: attempt to call field 'getversion' (a nil value)

I guess that means no?

$ uname -s
GNU/kFreeBSD

"uname -o" also has the exact same output.

I'm not very familiar with premake (in fact I didn't know a single thing about it before I started building Debian packages for 0 A.D.), but if it's too much hassle to make premake work nicely with kfreebsd, I could just carry this as a Debian-specific patch.

[vincent]

I've uploaded 0 A.D. to Debian with this patch and can confirm that it builds successfully on the Debian kfreebsd buildds as well, so 0 A.D. is now just an 'apt-get install' away for kfreebsd users. :)

Links to Debian's ​build logs: 0 A.D. on ​kfreebsd-i386 and ​kfreebsd-amd64

[ben]

In 11781:

Adds partial support for Debian GNU/kFreeBSD, based on patch by vincent. Refs #1322.

[leper]

Replying to vincent:

I guess that means no?

r11970 adds getversion to our premake and extends it to support POSIX-compilant systems. That should work for GNU/kFreeBSD too. Could you please test/confirm this?

[vincent]

Replying to leper:

Replying to vincent:

I guess that means no?

r11970 adds getversion to our premake and extends it to support POSIX-compilant systems. That should work for GNU/kFreeBSD too. Could you please test/confirm this?

Nope, the build still fails with "ld: cannot find -lexecinfo" like before.

The problem is that os.getversion().description doesn't output anything on Debian GNU/kFreeBSD. I've tried running 0ad's copy of premake with the example code in premake's ​user guide, i.e.

$ cat premake4.lua
local ver = os.getversion()
print(string.format(" %d.%d.%d (%s)", 
   ver.majorversion, ver.minorversion, ver.revision,
   ver.description))
$ ./premake4
 8.1.1 ()
Type 'premake4 --help' for help

(Yes, 8.1.1 is the kernel version being used in kfreebsd at the moment.)

Is there a way to get premake to just run uname? It seems to be a lot more reliable than os.getversion() is...

[leper]

Ah I guess the problem is somewhere in the way glibc (I assume this handles the uname syscall somehow) or how both kFreeBSD and Linux do this (see the comment in getversion()). The sysname (description in premake) is known in getversion put isn't known outside of that function. I also added os.outputof() to our premake (from upstream) so you could test if it works with that (calling with "uname -s"), though properly fixing the getversion call would be better (as that uses the uname() syscall that should provide the needed information (uname calls that too)).

[vincent]

I've tried replacing the os.getversion() call with os.outputof("uname -s"), but it still doesn't seem to work...e.g. even with just a simple premake4.lua file:

if os.outputof("uname -s") == "GNU/kFreeBSD" then
print("running kfreebsd")
end

premake doesn't output anything at all. On the other hand,

print(os.outputof("uname -s"))

prints "GNU/kFreeBSD" as expected. I suppose maybe the "/" is causing some problems?

[leper]

I suppose the attached patch fixes the GNU/kFreeBSD (or rather glibc) problem. It still puzzles me why it doesn't work with a simple pointer copy with glibc (but does work with both the OpenIndiana and the OpenBSD libc).

The strcpy throws a compiler warning as info.description is const char *.

[vincent]

I can confirm that applying the above patch fixes the linker error on GNU/kFreeBSD. Thanks!

[leper]

Thanks for testing it. I'll try to clean it up and will probably commit it soon.

[leper]

In 11993:

Fix premake's os.getversion() to work with glibc. Refs #1322.

[leper]

Just curious, but are there any remaining errors/problems on Debian GNU/kFreeBSD?

[vincent]

Argh, I should've tested a full build...there's another linker problem later on, i.e.

Linking Collada
../../../libraries/fcollada/lib/libFColladaSR.a(FUPluginManager.o): In function '~FUPluginManager':
/tmp/build/0ad/0ad/libraries/fcollada/src/FCollada/FUtils/FUPluginManager.cpp:183: undefined reference to 'dlclose'
../../../libraries/fcollada/lib/libFColladaSR.a(FUPluginManager.o): In function 'FUPluginManager::LoadPluginsInFolderName(fm::stringT<char> const&, char const*)':
/tmp/build/0ad/0ad/libraries/fcollada/src/FCollada/FUtils/FUPluginManager.cpp:151: undefined reference to 'dlopen'
/tmp/build/0ad/0ad/libraries/fcollada/src/FCollada/FUtils/FUPluginManager.cpp:155: undefined reference to 'dlsym'
/tmp/build/0ad/0ad/libraries/fcollada/src/FCollada/FUtils/FUPluginManager.cpp:156: undefined reference to 'dlsym'
/tmp/build/0ad/0ad/libraries/fcollada/src/FCollada/FUtils/FUPluginManager.cpp:157: undefined reference to 'dlsym'
collect2: ld returned 1 exit status

I propose the following patch:

diff -Nru a/build/premake/premake4.lua b/build/premake/premake4.lua
--- a/build/premake/premake4.lua	2012-06-22 02:27:34.000000000 -0700
+++ b/build/premake/premake4.lua	2012-06-22 02:30:50.000000000 -0700
@@ -1018,6 +1018,10 @@
 			links { "c", }
 		end
 
+		if os.getversion().description == "GNU/kFreeBSD" then
+			links { "dl", }
+		end
+
 		buildoptions { "-fno-strict-aliasing" }
 
 		buildoptions { "-rdynamic" }

With my patch applied, 0 A.D. builds perfectly fine on Debian GNU/kFreeBSD. :)

[leper]

I added my own patch (I'll have another dev look at it). I added GNU/kFreeBSD to the Linux branch as those two have more in common with each other (glibc and gnu userland).

I also exchanged the LINUX define in FCollada with the (compiler set) __linux__ and for the other supported OSs. I only tested it on Linux and OpenBSD, so some more testing would be great, though I don't expect much breakage.

The include header files were updated from the source ones, and I have removed lots of unneeded include guards (when including) as there are already guards in the header files. (We should probably fork the github repo from #562 as at least the __linux__ fix was already done there.)

[vincent]

I can confirm that latest svn + your patch builds fine on GNU/kFreeBSD.

[vincent]

FYI, Alpha 11 now builds fine on kfreebsd with the following very small and unintrusive patch:

--- a/build/premake/premake4.lua
+++ b/build/premake/premake4.lua
@@ -1040,6 +1040,10 @@
 			links { "c", }
 		end
 
+		if os.getversion().description == "GNU/kFreeBSD" then
+			links { "dl", }
+		end
+
 		buildoptions { "-fno-strict-aliasing" }
 
 		buildoptions { "-rdynamic" }

(Oops, just realized I've already attached the same patch earlier in the bug report...sorry for the noise.)

[ben]

In 12702:

Fixes build on GNU/kFreeBSD, patch by vincent. Fixes #1322