Skip site navigation (1)Skip section navigation (2)
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>