Date: Sun, 12 Dec 2010 12:57:46 +0200 From: Andriy Gapon <avg@freebsd.org> To: =?UTF-8?B?QmVybmhhcmQgRnLDtmhsaWNo?= <decke@bluelife.at> Cc: multimedia@freebsd.org Subject: Re: Call for Testers: XBMC 10.0 Message-ID: <4D04AAAA.3050603@freebsd.org> In-Reply-To: <1292143026.3455.2.camel@Nokia-N900-42-11> References: <20101208192132.51c9937f@FreeBSD.org> <4D03D5B5.8050709@freebsd.org> <1292143026.3455.2.camel@Nokia-N900-42-11>
next in thread | previous in thread | raw e-mail | index | archive | help
on 12/12/2010 10:37 Bernhard Fröhlich said the following:
> ----- Ursprüngliche Mitteilung -----
>> 1. Is this port i386-only? Specifically, there seem to be problems
>> compiling it on amd64 - some .Asm files get compiled into i386 code.
>
> No absolutely not. It was runtime tested for some weeks on amd64 and build tested in a tinderbox on 7, 8, current on amd64 and i386. Currently only failing on 7.
The problem that I see is compilation failing in
xbmc/cores/paplayer/SPCCodec/SNES/SNESAPU directory. I looked into the
top-level Makefile and I see that that directory is not supposed to included
into the build on x86_64 linux:
ifeq ($(or $(findstring powerpc,$(ARCH)),$(findstring
x86_64-linux,$(ARCH)),$(findstring arm, $(ARCH))),)
$(MAKE) -C xbmc/cores/paplayer/SPCCodec/SNES/SNESAPU
endif
amd64 FreeBSD should be excluded here too, most likely.
I fixed this by changing "x86_64-linux" => "x86_64".
But maybe I just screwed my build environment in the first place... Because I
had to restart configure and compilation steps a few times.
>> 2. There also seem to be problems compiling with gcc44+ from ports. Not
>> too drastic ones though - I'll send in couple of patches for this later.
1. Patch for configure.in to correctly detect and link libfaac.so:
@@ -721,8 +764,8 @@
AC_MSG_RESULT($faac_disabled)
else
if test "$use_faac" = "yes"; then
- AC_CHECK_LIB([faac], [main],,
- use_faac=no;AC_MSG_RESULT($faac_not_found))
+ AC_CHECK_LIB([faac], [main], LIBS="-lfaac -lstdc++ $LIBS",
+ use_faac=no;AC_MSG_RESULT($faac_not_found), [-lstdc++])
else
AC_MSG_RESULT($faac_disabled)
fi
The issue here seems to be that in my environment libfaac.so is linked with
libmp4v2.so and the latter is a "C++ library". That is, it depends on
libstdc++.so. But for some reason gcc44, unlike base gcc, doesn't pick up that
dependency automatically.
2. Patch for guilib/StdString.h.
@@ -2,6 +2,7 @@
#include <string>
#include <stdint.h>
#include <vector>
+#include <cstring>
#if defined(_WIN32) && !defined(va_copy)
#define va_copy(dst, src) ((dst) = (src))
This is needed because of the existing patch that introduces memset.
gcc44 unlike base gcc doesn't see memset definition through other headers, but
needs an explicit include.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D04AAAA.3050603>
