XCode changes for svn-14612 (10.5/10.4 compatible)
#1
Important notes regarding the recent SVN changes (14612) regarding the building of XBMC for Mac.

1) The project files and all internal lib makefiles have been changed to target the 10.4 SDK. This mean XBMC for Mac is now 10.4 and 10.5 binary compatible. For this to work correctly, the MacPort referenced libs need to be built on a 10.4 platform as it is not possible at the current time to build MacPorts libs on a 10.5 system to be 10.4 compatible. There is a MacPorts-mpkgs-1.0.zip archive available to download on the XBMC SourceForge project site that contains the current set of MacPorts libs referenced by XBMC on Mac. These libs are 10.4/10.5 compatible and are selfcontained (no need to install MacPorts). You have a choice to use the 10.4/10.5 compatible pre-built MacPorts libs or you can use your existing MacPorts install but remember that any MacPorts libs built on a 10.5 system will NOT work under a 10.4 system. If any MacPorts libs are missing from the mpkgs, please contact me and I can create an new MacPorts-mpkgs that include them.

2) The XCode project file has been purged of any non-referenced header/library references. Also any libs that do not have a make method or source code have been redirected back to a MacPorts built lib (ie. libcpio). Once a source code build is in svn, then they can be re-directed back. Just a note, libcpio in the mpkgs does have the osx patches.

3) There are several new targets, "configure", "clean libraries", "build libraries" and "build XBMCHelper". The "tiger" target has been removed as the "XBMC" target build is 10.5/10.4 compatible. "configure" is a deps of the "XBMC" target so don't worry about it. "clean libraries" and "build libraries" will clean/build the internal refs libs including ffmpeg. "build XBMCHelper" builds the XBMCHelper and places a copy at the xbmc root.

4) The ffmpeg headers that XBMC references have been updated to match the ffmpeg built headers. This is important as the ffmpeg ABI MUST match between the XBMC binary and the ffmpeg lib binary.

5) The internal libs have a uniform postfix of "-osx". This includes ffmpeg. Since they are now all built to 10.4 sdk, they will work under both 10.5 and 10.4. If a future build includes ppc, then the internal libs can be built universal so there is no need for a i386/ppc designation on internal libs. The same will apply to external libs.

6) I've been extremely cautious in making sure these changes will not break the build but one never knowsWink So I'm sure that there will be some adjustment time required as various items are tweaked.

Good Luck and enjoy as XBMC can now be built to run under both 10.4 and 10.5 Mac OS X systems.
Reply
#2
Nice work - I shall test it out this afternoon/evening.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#3
Watch out for iconv in CharsetConverter.cpp

the usual "char**" vs "const char**"

the const depends on it's configure when built. Something about caching.

MacPorts is "const char" as is 10.4. 10.5 is "char". I've reverted the change in CharsetConverter.cpp as this breaks the linux build. Have to come up with a better way to detect which flavor.
Reply
#4
And build using the debug configuration, the release build has linker problems that I need to track down.
Reply
#5
if you get errors about LONG_BIT, delete the following two files and rebuild python.

Quote:system/python/python24.zip
system/python/python24-osx.so

The python build will not detect an older 10.5 sdk built python and assume all is fine when it need to rebuild python against 10.4 sdk. So force it to rebuild.
Reply
#6
svn build fixed (14765)

new "clean python" target
800+ python build warnings fixed
missing new files added to project
iconv (char** vs const char**) issue fixed
Reply
#7
What specific ports are you having trouble building against the 10.4u SDK on 10.5 using Macports? I've built all the XBMC dependencies using the +universal variant (except SDL_mixer which requires smpeg3 which doens't build universal). In my case, however, I have universal_sysroot set to the 10.5 SDK, but a fresh install setting universal_sysroot to the 10.4u SDK should work fine. Have you filed tickets about these issues in the MacPorts trac? If so, give me ticket IDs, and I'll work on the issues.
Reply
#8
jeremyhu Wrote:What specific ports are you having trouble building against the 10.4u SDK on 10.5 using Macports? I've built all the XBMC dependencies using the +universal variant (except SDL_mixer which requires smpeg3 which doens't build universal). In my case, however, I have universal_sysroot set to the 10.5 SDK, but a fresh install setting universal_sysroot to the 10.4u SDK should work fine. Have you filed tickets about these issues in the MacPorts trac? If so, give me ticket IDs, and I'll work on the issues.

I'd have to backtrack and re-check, this was done several months ago. Using MacPorts-1.6.0, there was something about +universal not working. Also pkg creation was broke too.
Reply
#9
davilla Wrote:I'd have to backtrack and re-check, this was done several months ago. Using MacPorts-1.6.0, there was something about +universal not working. Also pkg creation was broke too.

Ok, well as of a few hours ago, all the ports you depend on build +universal.
Reply
#10
jeremyhu Wrote:Ok, well as of a few hours ago, all the ports you depend on build +universal.

This with MacPorts-1.6.0 ?

Did you check if they worked if built on 10.5 and run under 10.4? If I remember correctly, building +universal on 10.5 was not able to run under 10.4 because of missing symbol problems.

"nm <lib> | grep UNIX" to search for $UNIX2003 symbols that do not exist on 10.4.
Reply
#11
Yes, that is true that building +universal on 10.5 won't let you run it on 10.4. You need to take the extra step of setting your sysroot to be the 10.4u SDK.

Edit /opt/local/etc/macports/macports.conf
Change the universal_sysroot line (or add a new one if it's not present):

universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk

---

I haven't tested it myself. I know that ports marked 'universal_variant no' will NOT use that SDK. What you can do is edit your CFLAGS so it's always used (and not just when +universal). Add this to your CFLAGS, CXXFLAGS, and LDFLAGS:

-isysroot /Developer/SDKs/MacOSX10.4u.sdk
Reply

Logout Mark Read Team Forum Stats Members Help
XCode changes for svn-14612 (10.5/10.4 compatible)3