ATV SSHC builds and script error 126

I deleted the old logs and went through the process again. This time I moved XBMC_OSX_30020.tgz over to the frontrow directory on the AppleTV so that it was with the xbmc-9.04_update_sshcs.sh file and then ran:


XBMC.log is empty. It recreated it, but there's nothing in it. Here's CrashReporter.log.

davilla Wrote:Only builds targeting 10.4SDK are supported, if you target 10.5/10.6, you are on your own.

Ahhh, Error Status:5 was what I was seeing and I just figured it was still the issue from this old thread I found.

I'm wondering if TheQuestor ever went back to MacPorts 1.7?

KevinSartori Wrote:I deleted the old logs and went through the process again. This time I moved XBMC_OSX_30020.tgz over to the frontrow directory on the AppleTV so that it was with the xbmc-9.04_update_sshcs.sh file and then ran:

Code:

./xbmc-9.04_update_sshcs.sh XBMC_OSX_30020.tgz

XBMC.log is empty. It recreated it, but there's nothing in it. Here's CrashReporter.log.

Symbol not found: _strerror$UNIX2003

TheQuestor's macports install is wrong because he did not a ) follow the guide at http://code.google.com/p/xbmc-port-depends/ or b) follow the README.osx with respect to changing the default SDK or c) did not follow the README.osx and use +universal where indicated.

In any case, Installs from TheQuestor's site on AppleTV are borked until he fixes this problem with his macports.

davilla Wrote:Symbol not found: _strerror$UNIX2003

TheQuestor's macports install is wrong because he did not a ) follow the guide at http://code.google.com/p/xbmc-port-depends/ or b) follow the README.osx with respect to changing the default SDK or c) did not follow the README.osx and use +universal where indicated.

In any case, Installs from TheQuestor's site on AppleTV are borked until he fixes this problem with his macports.

Actually I have followed the guide to the letter since I have been doing this, and they have always worked with ATV until you guys changed everything around.

TheQuestor Wrote:Actually I have followed the guide to the letter since I have been doing this, and they have always worked with ATV until you guys changed everything around.

Care to be more specific about what was changed ? There's only one way to get a _strerror$UNIX2003 symbol and that's if you have built the binary against 10.5 SDK. That symbol does not exist under 10.4 SDK, it's just "_strerror".

My builds and that of the buildbot slaves are setup to build the listed why and they are runtime safe under the AppleTV. I recently cranked up another buildbot slave and purposely followed both guides to the letter to verify their accuracy and it was fine.

davilla Wrote:Care to be more specific about what was changed ? There's only one way to get a _strerror$UNIX2003 symbol and that's if you have built the binary against 10.5 SDK. That symbol does not exist under 10.4 SDK, it's just "_strerror".

My builds and that of the buildbot slaves are setup to build the listed why and they are runtime safe under the AppleTV. I recently cranked up another buildbot slave and purposely followed both guides to the letter to verify their accuracy and it was fine.

Until today, I haven't changed ANYTHING on my hackintosh in many months, not even security updates. Whenever there is a change to the readme.osx I do a "perl -ne 'print `port install $1` if /^ \$ sudo port install (.*)$/;' README.osx" and other than the nightly svn up I do not use that machine for anything. SO again it is not something "I" changed. And unless Mac's just tend to change things all by themselves or some elf of gnome came into my house and pudged with my hackintosh.

To make SURE it was right I deleted macports and went line by line by your readme [except all the ln -s where already there] and will try tonight.

Here is my build cmd
"./bootstrap
echo "Running Configure"
./configure --enable-goom
echo "Exporting PWD"
export XBMC_HOME=`pwd`
echo "Making Xcode Depends"
make xcode_depends
echo "Building"
xcodebuild -sdk macosx10.4 -project XBMC.xcodeproj -target XBMC.app -configuration Debug build"

from that crashreporter.log

Referenced from: /Applications/XBMC.app/Contents/MacOS/../Frameworks/libcdio.10.dylib

libcdio comes from macports, and checking for this symbol

Skunkworks:xbmc-svn davilla$ nm /opt/local/lib/libcdio.10.dylib | grep _strerror
U _strerror
Skunkworks:xbmc-svn davilla$

See, no "_strerror$UNIX2003" but "_strerror" is ref'ed. Thats correct if 10.4uSDK is setup in macports AND +universal is used when doing the port install. When XBMC.app is packaged, the libcdio dylib is copied into XBMC.app and it's internal paths fixed.

building xbmc has nothing to do with it, it's a macports problem.

So by nuking my macports and starting over fresh "should" eliminate the issue is this correct?

Well except now building is failing with crystalHD again, sigh. so much of this stuff is so intertwined it's not even funny.

TheQuestor Wrote:So by nuking my macports and starting over fresh "should" eliminate the issue is this correct?

Well except now building is failing with crystalHD again, sigh. so much of this stuff is so intertwined it's not even funny.

what does "nm /opt/local/lib/libcdio.10.dylib | grep _strerror" show ?