[MAC] HOW-To build XBMC for Mac with MacPorts on Mac OS X 10.5 using the 10.4 SDK [Archive]

View Full Version : [MAC] HOW-To build XBMC for Mac with MacPorts on Mac OS X 10.5 using the 10.4 SDK

jeremyhu

2009-01-12, 07:48

I can't recall which thread this was in, so I figured I'd start a new one properly titled for this topic...

If you want to build binaries distributable to 10.4 from your 10.5 box you should do the following.

1) Set the +universal variant in /opt/local/etc/macports/variants.conf
2) Choose the 10.4u SDK in /opt/local/etc/macports/macports.conf by adding these lines:

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

I previously forgot the universal_target line in the earlier thread but couldn't find it to make the correction.

Note that this will need to be done before building anything in Macports. You may also need to change the x11 prefix to be more 10.4 friendly if you plan to build X11 binaries:

x11prefix /usr/X11R6

n9mjg

2009-01-12, 17:51

So with the target set to 10.4 would this then be redistributable to the apple tv?

davilla

2009-01-12, 18:53

So with the target set to 10.4 would this then be redistributable to the apple tv?

yes, it should. I've not tested this myself yet but will be doing so shortly as this resolves build issues with using MacPorts as a dependency. That being building on 10.5 and running under 10.4.

Gamester17

2009-01-12, 20:43

If this work out smoothly, could/should the instructions be added to the wiki and to the SVN readme?
http://xbmc.org/wiki/?title=HOW-TO_compile_XBMC_for_Mac_OS_X_from_source_code
http://xbmc.svn.sourceforge.net/viewvc/*checkout*/xbmc/branches/linuxport/XBMC/README.osx

???

davilla

2009-01-12, 21:20

jeremyhu

2009-01-13, 08:59

The "if this works out smoothly" is the crucial part. If it doesn't work, then it is a bug with MacPorts, and I'll work to get that addressed.

Also, as of a few days ago, the version of Samba in MacPorts should work (meaning we don't need to pull in the older 3.0.x version). Unfortunately my main dev box crapped out on me yesterday before I had a chance to really test out the XBMC build from MacPorts, but it atleast ran for whatever that's worth ;)

We could possibly even update the list of ports to install to just 'XBMC' and note that it will pull in all requirements and install a MacPorts built XBMC.app in /Applications/MacPorts

davilla

2009-01-13, 09:16

tvont

2009-01-13, 23:28

is it already possible to use macports 1.7? And a pure 10.5 app?

davilla

2009-01-14, 01:17

is it already possible to use macports 1.7? And a pure 10.5 app?

macports 1.7, that's what the man says :)

"a pure 10.5 app" -> I have no clue what this means. XBMC built under 10.5 or 10.4 is not going to make it run any faster/better or worse. Mind that to be fully build on 10.5 you will need to rebuild ALL the libs. The XCode project only build about 20 percent of the libs which is why I'm spending time on getting the configure/make working.

tvont

2009-01-16, 01:18

davilla

2009-01-16, 02:14

davilla, thanks. my question was malformed, sorry (was really tired yesterday :-)). I meant, to use the 10.5 SDK . You say, by using 10.5 SDK within xcode, only 20% of the libs are beeing built currently?

All the libs are build correctly except MADDLL. What is not considered is if 10.5 or 10.4 sdk is used. Again, this does not matter running under 10.5 but under 10.4. There is no gain to build to 10.5sdk. It does not matter. There's no speed up/slow down, etc. Don't worry about it for now.

XBMC for Mac is a combination of the main binary (XBMC) along with codec and libs (both internal and dynamically loaded). If you look at the XCode project, the build libraries target only builds the internal libs using a call to run various bash scripts. These scripts are forced 10.4sdk. Plus python and ffmpeg are also forced 10.4sdk. And the codec building is run manually using scripts or some unknown process.

I started adding libs to the build libraries target but that quickly became unmanageable because the build had to do both configure/make which took time to run, this lead to creation of the manual build scripts and this lead to the current effort which is to fix the main configure/make to build everything correctly (either 10.5 or 10.4 sdk) and then mod the XCode project to leverage this functionality.

jeremyhu

2009-01-17, 10:32

davilla, thanks. my question was malformed, sorry (was really tired yesterday :-)). I meant, to use the 10.5 SDK . You say, by using 10.5 SDK within xcode, only 20% of the libs are beeing built currently?

In my testing, I forced the 10.5 SDK and it built/ran fine. You'd just need to set -sdk and MACOSX_DEPLOYMENT_TARGET on the command line. I'm sure there are some places that gets overwritten (but it shouldn't) in some of the build scripts...

jeremyhu

2009-01-17, 10:37

the current effort which is to fix the main configure/make to build everything correctly (either 10.5 or 10.4 sdk) and then mod the XCode project to leverage this functionality.

By "everything", do you mean both internal and external libs that we don't really need to build? If so, then I'd say that is wrong. If you want to allow someone to build libXXXX at the same time as XBMC, great, but make that a configure option and not by default. We'd much rather update libXXXX independently of XBMC and not have a separate version of it just for XBMC (I realize some libs need to be that way due to some wrapping you guys are doing, but that should be the exception rather than the rule)

davilla

2009-01-17, 19:21

By "everything", do you mean both internal and external libs that we don't really need to build? If so, then I'd say that is wrong. If you want to allow someone to build libXXXX at the same time as XBMC, great, but make that a configure option and not by default. We'd much rather update libXXXX independently of XBMC and not have a separate version of it just for XBMC (I realize some libs need to be that way due to some wrapping you guys are doing, but that should be the exception rather than the rule)

Here's an example. LibSDL and friends is a lib that XBMC uses. MacPorts also has that lib. The current XCode project links to static libs (.a) in /xbmc/libs/libSDL-OSX. While MacPorts does have SDL, it does not have the xbmc specific patches. The SDL in MacPorts will work but there will be small problems here and there.

The current XCode project does not build these SDL static libs, they exist as binaries in svn. There is a build script (buildSDL-osx.sh) that builds them but it's a manual process. We don't like binaries in svn and even more, dislike binaries in svn that don't have their build documented. That's why I added buildSDL-osx.sh as a stop gap measure to document the buiid. There's lots of "build-osx.sh" scripts scattered around. These are present to document the builds of most those binaries in svn. Yes, it's a hack but it's much, much better than a binary in svn that no one knows how to build because the dev who built it left the project.

The proper way to handle these SDL static libs is to included them in the configure/make, then have the Xcode project run something like "make libSDL" when building to create/check them. That way they stay up to date.

There are about 20 libs that the XBMC binary uses. A few are built by run scripts in Xcode, the others rely on binaries in svn.

Yes, there are several things very wrong with the current OSX build. I'm working on rectifying that situation but it takes time and effort. I inherited it from the previous XBMC for OSX devs who a) did not understand configure/make and b) did not understand Xcode. While what they did resulting in being able to build XBMC for Mac, it's a mess and hard to maintenance and almost impossible for anyone else but an expert to completely rebuild from scratch.

jeremyhu

2009-01-18, 07:31

... nothing to see here...

jeremyhu

2009-01-18, 07:43

Here's an example. LibSDL and friends is a lib that XBMC uses. MacPorts also has that lib. The current XCode project links to static libs (.a) in /xbmc/libs/libSDL-OSX. While MacPorts does have SDL, it does not have the xbmc specific patches. The SDL in MacPorts will work but there will be small problems here and there.

Yeah, I realize that "problem"... frankly that was (IMO) a bad design decision early on. Those patches should've been pushed back to developers or the XBMC "wrapping" should've been a small bit of code that interfaced between SDL and XBMC. The XBMC svn repo contains copies of 10s of other opensource projects (rather than just maintaining necessary patches for those other projects and filing bug reports with the maintainers of your dependencies)

The current XCode project does not build these SDL static libs, they exist as binaries in svn.

Ugg... even worse. I didn't realize that.

There is a build script (buildSDL-osx.sh) that builds them but it's a manual process. We don't like binaries in svn and even more, dislike binaries in svn that don't have their build documented. That's why I added buildSDL-osx.sh as a stop gap measure to document the buiid. There's lots of "build-osx.sh" scripts scattered around. These are present to document the builds of most those binaries in svn. Yes, it's a hack but it's much, much better than a binary in svn that no one knows how to build because the dev who built it left the project.

Well, I'm glad that is being addressed.

The proper way to handle these SDL static libs is to included them in the configure/make, then have the Xcode project run something like "make libSDL" when building to create/check them. That way they stay up to date.

There are about 20 libs that the XBMC binary uses. A few are built by run scripts in Xcode, the others rely on binaries in svn.

Yes, there are several things very wrong with the current OSX build. I'm working on rectifying that situation but it takes time and effort. I inherited it from the previous XBMC for OSX devs who a) did not understand configure/make and b) did not understand Xcode. While what they did resulting in being able to build XBMC for Mac, it's a mess and hard to maintenance and almost impossible for anyone else but an expert to completely rebuild from scratch.

Yeah, I understand that... and I'm certainly willing to help where I can... I'm good with autoconf, but lousy with XCode.

What I DO want is to figure out what libs we can avoid building from svn and instead use existing libs. For the ones that we can't do that for, I want to understand why and try to get the necessary changes accepted into upstream or atleast into Macports, so we CAN use them instead of what is in SVN. That will make the effort of going to ppc much more manageable since it will be multiple smaller tasks rather than one large task.

davilla

2009-01-18, 08:04

Yeah, I understand that... and I'm certainly willing to help where I can... I'm good with autoconf, but lousy with XCode.

What I DO want is to figure out what libs we can avoid building from svn and instead use existing libs. For the ones that we can't do that for, I want to understand why and try to get the necessary changes accepted into upstream or atleast into Macports, so we CAN use them instead of what is in SVN. That will make the effort of going to ppc much more manageable since it will be multiple smaller tasks rather than one large task.

FYI, just got done building the xbmc binary with codecs and libs from command-line :) Actually runs too. I might take you up on the autoconf help, I was stuck in autoconf hell two days ago.

Another FYI, there's some dev work going on to move to run-time wrapping. With run-time wrapping, then we can replace some of our static wrapped libs with system libs.

Gamester17

2009-01-19, 18:09

Another FYI, there's some dev work going on to move to run-time wrapping. With run-time wrapping, then we can replace some of our static wrapped libs with system libs.@jeremyhu, there is a very heated/active discussion about the use of system libraries here:
http://xbmc.org/trac/ticket/5416
(the same discussion applies to XBMC for Mac as well as its built from the same SVN branch)

:;):