#1322 closed defect (fixed)
[PATCH] FTBFS on Debian GNU/kfreebsd
Reported by: | Vincent Cheng | Owned by: | ben |
---|---|---|---|
Priority: | Nice to Have | Milestone: | Alpha 12 |
Component: | Build & Packages | Keywords: | patch |
Cc: | Patch: |
Description (last modified by )
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__)
Attachments (11)
Change History (46)
by , 12 years ago
Attachment: | fix-kfreebsd-ftbfs.patch added |
---|
follow-up: 3 comment:1 by , 12 years ago
comment:2 by , 12 years ago
Description: | modified (diff) |
---|
comment:3 by , 12 years ago
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 :)
comment:4 by , 12 years ago
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.
comment:5 by , 12 years ago
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 :)
follow-up: 7 comment:6 by , 12 years ago
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.
comment:7 by , 12 years ago
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)?
follow-up: 10 comment:8 by , 12 years ago
This happens:
Sorry about the low resolution...I haven't had any success getting Virtualbox's Guest Additions to work yet. :(
comment:9 by , 12 years ago
(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.
comment:10 by , 12 years ago
Replying to vincent:
Any updates? :) If this works for you, we can make the changes.
by , 12 years ago
Attachment: | fix-kfreebsd-ftbfs-v1.patch added |
---|
by , 12 years ago
Attachment: | buildlog-v1.txt added |
---|
by , 12 years ago
Attachment: | fix-kfreebsd-ftbfs-v2.patch added |
---|
by , 12 years ago
Attachment: | buildlog-v2.txt added |
---|
comment:11 by , 12 years ago
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.
by , 12 years ago
Attachment: | fix-kfreebsd-ftbfs-v3.patch added |
---|
by , 12 years ago
Attachment: | buildlog-v3.txt added |
---|
comment:12 by , 12 years ago
Ok, one step closer now...collada builds but has problems with linking; please see attached buildlog-v3.txt for details.
by , 12 years ago
Attachment: | fix-kfreebsd-ftbfs-v4.patch added |
---|
follow-up: 14 comment:13 by , 12 years ago
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.
comment:14 by , 12 years ago
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.
follow-up: 20 comment:15 by , 12 years ago
$ ./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.
comment:16 by , 12 years ago
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
comment:17 by , 12 years ago
Milestone: | Alpha 10 → Alpha 11 |
---|---|
Priority: | Should Have → Nice to Have |
comment:19 by , 12 years ago
Keywords: | patch added; review removed |
---|---|
Milestone: | Alpha 11 → Backlog |
follow-up: 21 comment:20 by , 12 years ago
comment:21 by , 12 years ago
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...
comment:22 by , 12 years ago
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)).
comment:23 by , 12 years ago
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?
by , 12 years ago
Attachment: | os_getversion_glibc.diff added |
---|
comment:24 by , 12 years ago
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 *.
comment:25 by , 12 years ago
I can confirm that applying the above patch fixes the linker error on GNU/kFreeBSD. Thanks!
comment:26 by , 12 years ago
Thanks for testing it. I'll try to clean it up and will probably commit it soon.
comment:28 by , 12 years ago
Just curious, but are there any remaining errors/problems on Debian GNU/kFreeBSD?
comment:29 by , 12 years ago
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. :)
by , 12 years ago
Attachment: | kfreebsd_collada.diff added |
---|
comment:30 by , 12 years ago
Keywords: | review added |
---|---|
Milestone: | Backlog → Alpha 11 |
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.)
comment:31 by , 12 years ago
I can confirm that latest svn + your patch builds fine on GNU/kFreeBSD.
comment:32 by , 12 years ago
Milestone: | Alpha 11 → Backlog |
---|
by , 12 years ago
Attachment: | fix-kfreebsd-ftbfs-v5.patch added |
---|
comment:33 by , 12 years ago
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.)
comment:35 by , 12 years ago
Keywords: | review removed |
---|---|
Milestone: | Backlog → Alpha 12 |
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. :/