From owner-freebsd-multimedia@FreeBSD.ORG Sun Dec 12 10:57:52 2010 Return-Path: Delivered-To: multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FEEA1065672; Sun, 12 Dec 2010 10:57:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3845F8FC18; Sun, 12 Dec 2010 10:57:50 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA02406; Sun, 12 Dec 2010 12:57:48 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PRjci-000BYn-3n; Sun, 12 Dec 2010 12:57:48 +0200 Message-ID: <4D04AAAA.3050603@freebsd.org> Date: Sun, 12 Dec 2010 12:57:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: =?UTF-8?B?QmVybmhhcmQgRnLDtmhsaWNo?= References: <20101208192132.51c9937f@FreeBSD.org> <4D03D5B5.8050709@freebsd.org> <1292143026.3455.2.camel@Nokia-N900-42-11> In-Reply-To: <1292143026.3455.2.camel@Nokia-N900-42-11> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: multimedia@freebsd.org Subject: Re: Call for Testers: XBMC 10.0 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 10:57:52 -0000 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 #include #include +#include #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