[LINUX] Enable separate 32/64-bit libraries for linux addons #2000

wants to merge 1 commit into


None yet
4 participants

maysl commented Dec 28, 2012

sotrry, corrupted the original pull request found here: #1061


theuni commented Dec 28, 2012

There is no need for this. Just like ubuntu and all of the other major distros, the addon you get will depend on the repo you get it from. ie you don't 'apt-get install firefox-amd64', you 'apt-get install firefox' and your distro knows that you're running am64, so it fetches from that repo.

If you installed an amd64 xbmc, the distro should either bundle a repo addon that provides addons for your arch, or provide you with packages for the addons themselves.

Otherwise things would get out of hand very quickly.. x86/x64/arm/mips/new x32 abi/, etc.

In addition, an addon for one distro may not work with another due to changes in deps, paths, etc.

The other OSs have stable abi's and we're in control of shipping binaries. For Linux, we just have to accept that it's different and cater towards the distros.

Let's take two examples, ubuntu and openelec.

Ubuntu ships in many abis and many versions. addon-foo.so may work on Precise because it depends on systemlib-bar.so.1, but Quantal only supplies systemlib-bar.so.2. So already, you need 2 versions of the addon. Now, you need to build for amd64/x86/arm. So we're up to 6 versions.

In this scenario, the distro (Ubuntu) should build the addons and create additional packages for them, so that they can be fetched via apt-get. apt-get xbmc-pvr-foo. This way, addons update just like any other system package.

Now for openelec:

Afaik, it does not include any kind of package manager, so apt-get is out of the question. However, it builds for limited abis. In this case, for the x86 build (for example), openelec should add a repository.openelec.pvr-addons-x86 (et al), which provides the addons to it users.

It's complicated, but it's really the only way that makes sense for Linux.

maysl commented Dec 29, 2012

You are absolutely correct as far as package installs are concerned.

However, there are other ways of installing binary addons (manual and addon repository). In these cases, it is probably much more user friendly to have both libs in one package.

The systemlib-bar.so.? problem can be addressed by static linking and compiling on a safely old system. I have done this before for the fishBMC visualization addon, and it worked just fine. But I always had to trust the user to download the correct version.

But - considering the fact, that I am probably the only developer to profit from the change - and not for long, as I really hope fishBMC gets pulled into xbmc - the benefit of this feature is probably negligible.


MartijnKaijser commented Aug 6, 2013

could you have a look at this and see if we are interested in this?


wsnipex commented Aug 6, 2013

I agree with theuni, we don't need this. We use proper packaging also for binary addons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment