notaz
Certified Guru
glib could probably be updated in OS, it shouldn't be as problematic as updating something like QT.
glib/GTK update tentative [Split from Pidgin thread]
- Thread starter notaz
- Start date
ptitSeb
Serial Porter
OOOh ! That would be great if you could do that, as many things are rather difficult to compile because they need a more recent glib (like at least a 2.30).
sebt3
homebrew player (P. & C.)
And if you do so, update GTK too please.
notaz
Certified Guru
It looks like there were quite a few ABI changes though, chances are some PNDs will break:
http://upstream-tracker.org/versions/glib.html
Hopefully benefits will outweight the problems..
http://upstream-tracker.org/versions/glib.html
Hopefully benefits will outweight the problems..
That's a whole different weight category..
notaz
Certified Guru
Ok compiled glib 2.34, installed on my pandora and Xfce no longer starts, seems to be crashing.
glib is really not keeping binary compatibility, good thing I haven't pushed out an update for everyone..
About making different versions coexist, OE doesn't offer such functionality, and it's like creating a fork anyway, maintaining compatibility for these PNDs linked against a fork will only bring headaches in future. It won't solve the problem anyway - say some PND is linked against a forked glib and a few other libs in firmware; but one of those firmware libs is linked against "main" glib. You end up having both glibs loaded into the same process, lots of duplicate name functions (but with different content) in symbol table, and the dynamic linker will link random function to your program, so you crash anyway.
glib is really not keeping binary compatibility, good thing I haven't pushed out an update for everyone..
About making different versions coexist, OE doesn't offer such functionality, and it's like creating a fork anyway, maintaining compatibility for these PNDs linked against a fork will only bring headaches in future. It won't solve the problem anyway - say some PND is linked against a forked glib and a few other libs in firmware; but one of those firmware libs is linked against "main" glib. You end up having both glibs loaded into the same process, lots of duplicate name functions (but with different content) in symbol table, and the dynamic linker will link random function to your program, so you crash anyway.
Last edited by a moderator:
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Well, if you can figure it out, great! If not, oh well at least you tried. Right?
notaz
Certified Guru
Sort of a progress report from last night:
After recompiling xfce4-session Xfce started again, but it's broken all over the place, gnome-keyring errors out so no wifi, even terminal doesn't start. Logs show lots of errors from gtk, so I tried recompiling it but of course it failed because it relies on some macros in old glib. Then tried updating gtk, but problems there again as newer gtk was split into 2 libs (gdk-pixbuf split out). Recipe from newer OE failed but after more hacking it finally compiled, after more pain gtk compiled too. Starting OS build now resulted in yet another failure of atk lib, again because of glib, updating that we get glade failing to build, but haven't checked that one yet.
So it's horrible dependency hell, I wish I never started this. Makes me wonder how distribution maintainers cope with all this, I guess picking all newest versions of everything results in somewhat working system as the developers are using everything this way, but it seems updating single gnome component is just suicide.
After recompiling xfce4-session Xfce started again, but it's broken all over the place, gnome-keyring errors out so no wifi, even terminal doesn't start. Logs show lots of errors from gtk, so I tried recompiling it but of course it failed because it relies on some macros in old glib. Then tried updating gtk, but problems there again as newer gtk was split into 2 libs (gdk-pixbuf split out). Recipe from newer OE failed but after more hacking it finally compiled, after more pain gtk compiled too. Starting OS build now resulted in yet another failure of atk lib, again because of glib, updating that we get glade failing to build, but haven't checked that one yet.
So it's horrible dependency hell, I wish I never started this. Makes me wonder how distribution maintainers cope with all this, I guess picking all newest versions of everything results in somewhat working system as the developers are using everything this way, but it seems updating single gnome component is just suicide.
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Ah well, I wouldn't bother then. Will the Pyra at least have the right version?
ptitSeb
Serial Porter
I do agree and share the pain! I tried also to updated glib and friends for codeblocks... And yes, dependencies hell!
mcobit
Advanced Member
- Joined
- Jul 28, 2008
- Messages
- 6,909
Only solution I could think of is to install them seperately in /usr/local for example and package them in a pnd that overlays them to the correct system path when mounted. So application maintainers need to get them from there if newer programs need them.
notaz
Certified Guru
It still won't work if the PND loads any "usual" libs that use glib too, it all will just crash.
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Then it just needs to include ALL libs that use glib inside the PND. Yes, that will make the PND very large, but it's worth it.
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Well hopefully Fahrstuhl can do that with Pidgin.
comradekingu
Glowing ember
In debian glibc is behind, and xfce4 isnt new. I hope LXqt can replace it so that one is more free to ship updated libraries.
notaz
Certified Guru
glibc is not involved, it's doing a real good job maintaining the ABI and has versioned symbols in case they need to change anything.
It's GLib (GNOME Lib?).
It's GLib (GNOME Lib?).
notaz
Certified Guru
Ok after lots of pain I have got the latest glib and gtk2 building, xfce seems to be booting and working.
I hope I can get some help with testing before it's all pushed to main OS update as lots of other libs had to be updated to build and work with latest glib.
To test, you have to change /etc/opkg/openpandora.org-feed.conf to point to my test feed instead:
Then run OS update as usual.
Edit: everything has been pushed to official feeds as 1.62-rc, see 1.62 thread:
http://boards.openpandora.org/topic/17176-superzaxxon-v162rc-released/
I hope I can get some help with testing before it's all pushed to main OS update as lots of other libs had to be updated to build and work with latest glib.
Edit: everything has been pushed to official feeds as 1.62-rc, see 1.62 thread:
http://boards.openpandora.org/topic/17176-superzaxxon-v162rc-released/
Last edited by a moderator:
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
As I need my Pandora, I can't help you test this, but I really hope it works out! 
Just upgraded as well and have to give out a small warning:
After upgrading and rebooting, XFCE4 didn't run (always went back to the login screen).
I booted into CLI mode and renamed my home-directory in order to get a clean one.
After doing that, it booted up find and is working without issues so far.
On my old profile, I changed some things such as font sizes, etc.
Seems like the profiles are not 100% compatible, so for an official update, we probably need to delete custom XFCE4-Settings before the upgrade.
After upgrading and rebooting, XFCE4 didn't run (always went back to the login screen).
I booted into CLI mode and renamed my home-directory in order to get a clean one.
After doing that, it booted up find and is working without issues so far.
On my old profile, I changed some things such as font sizes, etc.
Seems like the profiles are not 100% compatible, so for an official update, we probably need to delete custom XFCE4-Settings before the upgrade.
Similar threads
