Tiny Core Linux
Off-Topic => Archive / Obsolete => SCM EXtensions => Topic started by: Jason W on March 14, 2012, 08:24:53 PM
-
Gtk3 and it's apps are broken with Xorg 7.6. I one day will get around to fiddling with it, but for now the gtk3 apps can just be used with Xvesa. I am not sure I will spend too much time right now with gtk3, but I will investigate.
-
I've been saying that it was not my job:
http://forum.tinycorelinux.net/index.php/topic,12689.msg69321.html#msg69321
you know that I do cheering for you jason
-
I tried building with Xorg running, made no difference.
I don't know what the issue is, either an issue with our build of Xorg (which works with everything else, also it is the latest Xorg release, so not likely the issue), or something about gtk3 or it's dependencies.
I will revisit one day in the future.
-
Also I did both tests, with Xvesa and Xorg 7.5, but unfortunately nothing to do
-
tc@box:~$ gtester /apps/bin/l3afpad-bin
TEST: /apps/bin/l3afpad-bin... (pid=7695)
/apps/bin/l3afpad-bin: error while loading shared libraries: libgdk-3.so.0: cannot open shared object file: No such file or directory
FAIL: /apps/bin/l3afpad-bin
Terminated
tc@box:~$ gtester /apps/bin/emelfm2-gtk3-bin
TEST: /apps/bin/emelfm2-gtk3-bin... (pid=7698)
/apps/bin/emelfm2-gtk3-bin: error while loading shared libraries: libgdk-3.so.0: cannot open shared object file: No such file or directory
FAIL: /apps/bin/emelfm2-gtk3-bin
Terminated
tc@box:~$
tc@box:~$
tc@box:~$ gtester /apps/bin/l3afpad
TEST: /apps/bin/l3afpad... (pid=7768)
l3afpad: Unknown option --quiet
FAIL: /apps/bin/l3afpad
Terminated
tc@box:~$ gtester /apps/bin/emelfm2-gtk3
TEST: /apps/bin/emelfm2-gtk3... (pid=7772)
/apps/emelfm2-gtk3/bin/emelfm2-gtk3-bin: unrecognized option '--quiet'
/apps/emelfm2-gtk3/bin/emelfm2-gtk3-bin: invalid option -- '='
/apps/emelfm2-gtk3/bin/emelfm2-gtk3-bin: invalid option -- 'q'
usage: emelfm2 [option]
PASS: /apps/bin/emelfm2-gtk3
tc@box:~$
tc@box:~$
-
Gtk3 and it's apps are broken with Xorg 7.6. I one day will get around to fiddling with it, but for now the gtk3 apps can just be used with Xvesa.
I don't know what the issue is, either an issue with our build of Xorg (which works with everything else, also it is the latest Xorg release, so not likely the issue), or something about gtk3 or it's dependencies.
The "guilty" is libX11.so.0.6.3 from Xlibs.tcz...Was it compiled with some custom option?
To check it, you can do (with Xorg running):
Download: http://www.x.org/releases/X11R7.6/src/everything/libX11-1.4.0.tar.bz2 (http://www.x.org/releases/X11R7.6/src/everything/libX11-1.4.0.tar.bz2)
Untar and cd into
tc@box:~/libX11-1.4.0$ tce-load -iw compiletc Xorg-7.6-dev libxcb-dev #compile dependencies
tc@box:~/libX11-1.4.0$ ./configure --prefix=/usr # /usr because libX11 from Xlibs is into /usr/lib
tc@box:~/libX11-1.4.0$ make
tc@box:~/libX11-1.4.0$ sudo make install # overwrite libX11
Then you can run gtk3 applications without problems...(Only tested with Xorg 7.6)
-
Thanks for the find. I don't maintain Xorg but maybe Curaga can perhaps test a rebuild and if this is the case perhaps update Xlibs.
-
Even easier: Since libx11-xcb.tcz has correct libX11.so files we can do:
tc@box:~$ tce-load -iw libx11-xcb
tc@box:~$ sudo ln -f -s /tmp/tcloop/libx11-xcb/usr/local/lib/libX11.so.6.3.0 /usr/lib/libX11.so.6.3.0
tc@box:~$ sudo ln -f -s /tmp/tcloop/libx11-xcb/usr/local/lib/libX11.so.6.3.0 /usr/lib/libX11.so.6
tc@box:~$ sudo ln -f -s /tmp/tcloop/libx11-xcb/usr/local/lib/libX11.so.6.3.0 /usr/lib/libX11.so
With this, we change symbolic links to point to libX11 from libx11-xcb instead from Xlibs.
And then we can do:
tc@box:~$ scm-load -iw l3afpad
tc@box:~$ l3afpad
-
That is ok as a workaround but I will pm Curaga and see if he is interested in rebuilding libX11.
-
Our libX11 is 1.3.6, a standard working build. It seems like gtk3 requires xcb (which libX11 starting 1.4.0 also requires).
I'm not willing to force-add that bloat to the base (Xlibs) just yet. As I see it now, it's 5.0 material.
-
Further check to the errors is that gtk3 seems to use Xlib from multiple threads, which is not really supported without xcb. Had it directly required XCB, it would've said so configure-time and saved some time :P.
-
Our libX11 is 1.3.6, a standard working build. It seems like gtk3 requires xcb (which libX11 starting 1.4.0 also requires).
As far as I remember, 1.3.x series also require xcb (it needs explicit ./configure --without-xcb to avoid xcb).
Therefore all others distros works with gtk3...They have a standard libX11 build.
-
I define "requires" as in can't be built without. 1.3 series still could.
-
Response from irc.gnome.org #gtk+ is that gtk3 should still be working without xcb. I'll open a bug.
edit: https://bugzilla.gnome.org/show_bug.cgi?id=674465
Jason and others, please comment there with any requested info etc.
It also seems 3.4.0 is out, could anyone test it?
-
I define "requires" as in can't be built without. 1.3 series still could.
I understand...yes, with 1.4 xcb can not be avoided.
It also seems 3.4.0 is out, could anyone test it?
Yesterday I tried 3.4.1 -- No luck, same failure.
-
Ok, if the issue is needing xcb, that can easily be packed into the gtk3.scm extension.
And I reckon a shared gtk3 build can depend on the libx11-xcb.tcz extension.
-
It needs xcb (libX11-xcb.so) and libX11 libraries compiled with xcb support. Then:
a) For smc extensions you can compile and pack both and set LD_LIBRARY_PATH into script.
b) For a gtk3.tcz extension, one problem:
libx11-xcb.tcz puts libraries into /usr/local/lib. Then you have two libX11.so (one into /usr/lib from Xlibs, other into /usr/local/lib from libx11-xcb).
As /usr/lib takes precedence over /usr/local/lib gtk3 applications still use libX11 from Xlibs and crashing.
Some options:
a) Rebuild Xlibs with xcb support
b) Remove Xlibs symbolic links affected with tce.installed script when libx11-xcb.tcz loads.
-
Ok, I will compile a new xcb enabled libx11 and xcb into the gtk3.scm extension so we can move forward with gtk3 scms.
I am not sure how it is to be handled in the tcz area since replacing libX11 symbolic links during runtime, when apps that are linked to libX11 might be running, may not be what is wanted.
-
I'll also update to the latest gtk3, I will aim for tonight and see if that makes a difference.
-
Updated gtk3 to latest 3.4.1 as well as underlying libs, built libX11 with xcb support as part of extension, and the apps crash now even with Xvesa. I copied over the libX11 files to /usr/lib and restarted Xvesa to see if the libX11 with xcb support needs to be running. Still a no go.
I will rebuild with the previous version of gtk3 and see how that goes with the xcb enabled libX11
-
I rebuilt gtk3-2.3.4 with xcb enabled libX11, and now gtk3 apps work with a running Xorg but not without.
I will see if I can't find what will allow gtk3 to work with both Xvesa and Xorg.
-
For Xvesa you need libxcb.so.1.1.0 from libxcb.tcz.
I modified actual gtk3.scm adding under /lib:- libX11.so.6.3.0
- libX11-xcb.so.1.0.0
- libxcb.so.1.0.0
... and making their related symbolic links. No need to modify any application script.
Result: Working fine with Xvesa and Xorg.
-
Yeah, plugging in those files from the existing extensions works, but I am also interested in why those same files built from source, even from the same versions along with the latest gtk3, don't work, with or without pthread-stubs enabled in libxcb, or even the same versions as the existing extensions.
But those same files built from the current versions upstream work when plugged into the existing gtk3.scm extension, just like the files from the extensions do. And until we can build the latest gtk3 and it's latest dependencies, we can't move forward with it.
This afternoon I will plug those files in as a workaround.
-
Today I modified gtk3.scm with lastest gtk3 and here it is working (with both Xvesa and Xorg).
I added/replaced libraries:
a) From existing tcz's:
- libxcb.tcz
- libx11-xcb.tcz
- glib2.tcz
b) Compiled by me:
- pango 1.30
- gdk-pixbuf 2.26.1
- gtk3 3.4.1
I had to be careful when making new symbolic links. Errors are typical there.
-
Response from irc.gnome.org #gtk+ is that gtk3 should still be working without xcb. I'll open a bug.
It doesn't look like there's been much response on the bug report?
The need for gtk3 is starting to block updates of several extensions - the nodbus thing doesn't have a nogtk3 option does it ;)
-
Well, sw doesn't expire ;) Just like we still offer gtk1 apps, gtk3 doesn't remove the gtk2 ones.
-
Sure, and I still use the gtk1 apps beaver/emelfm/gtkfind every time I use tc.
..but, we're starting to reach the stage where bug fixes are not accessible because the latest versions of some applications require gtk3.
Anyway, nothing to be done until gtk3 is fixed :)
-
For making a working gtk3.tcz, I solve this by setting rpath (or runpath) into LDFLAGS variable when compiling gtk3...
Also I can send a working (and updated) gtk3.scm if needed.
-
Yeah, send in a runtime scm with it's locales intact, and also a gtk3-dev.tar.xz that is the full source to build against.
Thanks.
-
I'll test some, and perhaps this rpath variable is something that needs to be put in buildscm itself to perhaps save some headaches in future apps.
-
Actually, if you would send it in complete with the development files, after removing the large *.a static archives. This only adds 1 MB to the already 22MB gtk2.scm extension, so I have added the -dev parts to make it simple to build against. If we are going to turn a 6 or 7 MB extension into a 21MB one by including locales, may as well make it 22MB complete with the development files.
-
Done. Updated to 3.4.3 with development and locale files. Now it's about 20MB.
Is there any possibility of accepting tcz version?
-
Thanks.
Sure, a tcz version would be fine to me, as I really was not planning to be the one to do it, though vinnie was working on one until we ran into the issues.
-
Also, the build scripts and patches used would be good to have as well. Thanks.
-
Neither build script nor patches was used to build gtk3 for scm extension.
-
Did a working gtk3.tcz and gtk3-dev.tcz ever come out of this? :)
-
A working gtk3.tcz (and -dev, -locale, -doc) extension is ready, but it needs pango and gdk-pixbuf2 update...
-
Please feel free to update pango and gdk-pixbuf2, but if not I will aim to get to it shortly.
-
Ok, I will do it in the next few days...
-
I wonder if this has anything to do with the libxcb problem:
$ grep -l 'libxcb' /usr/local/lib/*la
/usr/local/lib/libcairo-gobject.la
/usr/local/lib/libcairo-script-interpreter.la
/usr/local/lib/libcairo.la
libxcb is not listed as a dep of cairo and libcairo does not depend on it.