Closed quasar1 closed 9 years ago
I have no experience with this I'm afraid. glibc is such a core lib that everything depends on so you probably have to rm -rf
your build and sysroot directories and be prepared that other libs and programs might have to be updated to newer versions too if they now no longer compile.
Yes, I deleted the whole xbmc folder when I installed the new test build, and when I built xbmc it was fresh with the new glibc/toolchain. I kind of figured this would be an invasive move when touching the toolchain, so already had it in mind to make a separate test branch with the toolchain changes in place to test its stability first before adding the udev and cec changes. It turns out I need to update GCC to at least 4.3 to work with glibc 2.11. This is proving rather tricky as now glibc cannot find -lgcc. I will persevere a bit longer as I have come this far...
@quarnster I have managed to update the toolchain to GCC 4.4.4 and glibc 2.11. I haven't tested or added the CEC things mentioned above yet, but I have another quick question. I understand we might be 'stuck' with kernel 2.6.28, but I was looking at the new 3x kernel versions and it mentions it has kernel 26 support. Do you think it's possible to update the kernel to version 3x ? I'm thinking there might be issues has it wouldn't match the current version on the Boxee? If we can then I was thinking of going all out and updating to GCC 4.9, glibc 2.19 binutillities 2.23-2. I would do it it stages to make sure there weren't any regressions.
Updating the kernel as in using the newer kernel sources to build all tools might work. Not something I've tried though. Actually flashing a 3x kernel wouldn't work unless someone figures out how to break the signature validation or if the RMA kernel supports kexec to load a second kernel or can be hacked in some other way.
Again I have no experience with this, you might have a better chance asking some linux experts on irc or something if you run into issues.
Thanks for the info. I think once I have tested GCC 4.4.4/glibc2.11 and then added the CEC changes I will try GCC 4.6 and whatever binutilities and glibc version work together. I know I will have to patch some of the kernel files to make it work with any GCC 4.6 and above as they don't support linker-style architecture options anymore. And thinking about it, that may be something else to look into as when we build the kernel we are using the native GCC which in my case on this Ubuntu VM its using GCC 4.6. If I succeed there I will try GCC 4.9, then see if the toolchain kernel can be updated to 3x, shame we can't hack the Boxee to get a newer kernel installed. It would be interesting to see if a kernel update would fix some of the audio issues people seem to be having, unless it's totally driver related.
Audio problem is started here whene keyzer added the audio options(analoge selection etc) before never had audio drops, also boxee software is ok with dts-ac3(so no driver related i think. on hd audio probl what is a hdmi driver bug)
I'm still bashing away at this, a number of issues when I finally got it to compile..
/tmp/mnt/nas-xbmc/xbmc.bin: /lib/libc.so.6: version `GLIBC_2.10' not found (required by /tmp/mnt/nas-xbmc/xbmc.bin)
/tmp/mnt/nas-xbmc/xbmc.bin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./libsmbclient.so.0)
/tmp/mnt/nas-xbmc/xbmc.bin: /lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by ./libstdc++.so.6)
There are various things you encounter with different versions of the various components that make up the toolchain, I think I have fixed the above but I'm leaning towards the latest kernel and newest revisions that make up the toolchain. This would allow me to dump the ancient udev so I can attempt to build the newer systemd. I have been fiddling with the new kernel.config settings options and how to get that compiled in too. It doesn't seem to have a version.h
in include/linux
any more so thinking about copying one in there to see if that works.
I might be a while though.. lol
Look's like I have come to the end of the road on this one. Having been successful in getting a toolchain working the builds it produces will not launch without this error (taken from the xbmc.log on the Boxee)
/tmp/mnt/nas-xbmc/xbmc.bin: error while loading shared libraries: ./libstdc++.so.6: ELF file OS ABI invalid
I don't quite understand the hack side of whats going on and whether it or the existing kernel/software/libc has any influence during the boot process or not. There were a few other things I was going to try but I am all running out of ideas now.
If anyone wants to test a build I made with newer kernel headers just shout and I'll upload it here. I doubt it will fix anything but it would be interesting to see if it gives any improvements or even to find out if it causes issues, which means I can ditch the idea altogether. I still can't get my head around what happens when the Boxee boots xbmc, whether the main Boxee kernel is still running in the background.
Seems this is the only way the Boxee will get any form of kernel update in its foreseeable future, so worth a punt.
i can test for you no problem :).
About the kernel, if you use new headers it still boots the boxee kernel 2.6 nothing you can change(or you must have a singing key)
https://www.sendspace.com/file/j1niho I used a generic v3.0 Linux i386 kernel conf.
Thanks, let you know how it works.
Tested some video and addons and to me it seems to be fine(but no different with older headers)
That's good in a way because I will need to update the kernel headers to v3.0+ to get any GCC above 4.6 working in the toolchain. I'm currently setting up a new Oracle VM based on Ubuntu 14.04 LTS 32 bit as I have run into issues on the old 12.04 LTS image. It seems the only way to get a new toolchain built based on the newer GCC/Glibc/Binutils.
Ah ok, if i need to test let me know, now tested rtmp etc also seems to work nicly :)
Well I haven't given up on this, I am making some progress, albeit rather slow. It turns out the new toolchain components don't like having the host, target and build type all the same (i686-pc-linux-gnu), which is what I have. The older versions we were using must have been more lenient this situation. I will have to try and get around the issue somehow, if I can't do it without too many complicated changes I probably throw in the towel.
I managed to get GCC 4.91 and Glibc 2.19 in a working toolchain but I still get
xbmc.bin: error while loading shared libraries: ./libstdc++.so.6: ELF file OS ABI invalid
when trying to boot the new build.
So, this looks to be impossible as the ABI is too new for the Boxee's old ABI.
Now, thinking out loud would it be possible to update the GCC and Glibc on the Boxee itself?
Probably too risky..... ??
@quarnster Just having a bash at getting udev, lockdev, libcap compiled to get cec adapter detection working. Long story short, udev 1.5.1 (oldest one compat with the 2.6.28 kernel and minimum required for cec) required me to update toolchain glibc 2.7 to 2.9. I got everything to complie and xbmc to see udev, libcap and cec (it no longer uses libusb as it uses libudev).
Now I see in the logs:
After googling i found this.. http://stackoverflow.com/questions/7647818/glibc-elf-file-os-abi-invalid
Don't quite understand what they mean, maybe I need a slightly newer glibc? Any advice or thoughts?
Edit: Seems I need glibc 2.11 http://upstream-tracker.org/changelogs/glibc/2.11/changelog.html
Still would appreciate any advice, especially if you think it still won't be possible..