Big experiment for "Wary 5.2"

I am conducting a big experiment for the next jump in Wary, which will be version 5.2.

1. Remove libxcb
The libxcb used with Xorg 7.3 has an incompatible API with the current libxcb. I think this may cause applications to fail if I want to apply a big Xorg upgrade PET to Wary with a later libxcb.
The solution is to remove libxcb entirely from Wary. An upgrade Xorg PET can introduce libxcb and there will be no clash.

2. GTK 2.24.5
This is the last of the 2.x series. I don't think that I will ever go up to GTK3, I'll retire before that. It makes sense to move Wary up to this version, and from then on, no need to upgrade ever again, unless they bring out a 2.24.x bugfix release.

With regard to point-1, the vast majority of applications can be compiled without dependency on any of the xcb libraries. There are some apps however, and I can't think which right now, that do require libxcb -- they cannot be used in the base Wary system, not without an Xorg upgrade.

What I'm trying to do is set up Wary to very easily lift itself up by it's bootstraps and run later Xorgs, so work on any video hardware. Without library conflicts.

So, how far have I got with this experiment? I'm running it right now. This is what I have been working on, when I very reluctantly got dragged back to do the emergency bugfix for Wary 5.1.4.

Packages that have been upgraded/recompiled/removed so far:



There is a slight difference with glibc, I am using kernel 2.6.32 headers, upgraded from 2.6.30, hence needed to recompile glibc.

Not everything is working. Abiword and Gnumeric for example look for libxcb, so I will recompile those. SeaMonkey is working, using it now.

Interesting, I have just recompiled gtksourceview, as it wanted libxcb. During compile it wanted libxcb.la so I just created a dummy file and it compiled. So something in the system is still telling to look for libxcb.la and libxcb-xlib.la.

---

Comments

xcb might not be a problem
Username: BarryK
But, if applications do not access libxcb directly, only via lib libX11, then upgrading Xorg would isolate the apps from changes in the libxcb API. So maybe my elimination exercise is not necessary.

An experiment
Username: BarryK
"I must emphasise that this is an experiment. It is not what will definitely happen for Wary 5.2. Dropping xcb might not be a good idea, as it might mean lots of PETs already created for Wary might be broken. Upgrading GTK though, is probably a good idea.

libxcb
Username: mave_org
"I don't and can't use Wary all day, because I need Xorg-Upgrade 7.5 and with it, many compile runnings end wirth libxcb errors. Good to solve this. Please make it possible running Seamonkey 2.x as an option to 1.x.

libxcb
Username: B
éèm"In some puppy's I had to install libxcb in order to have pidgin working. I'll test it and report on this when appropriate.

libxcb
Username: BarryK
"mave, It might be too difficult to solve. If I had created Wary originally without libxcb, then it would have been good. But, now so many PETs have been created, and the executables want libxcb, even if it is not used. Unless... is it possible to create an empty libxcb.so.* and libxcb-xlib.so.*? Take Abiword for example, it is using libgoffice, and that wants libxcb. However, I don't think that it uses it, not directly. libgoffice calls libX11, and that calls libxcb.so.* and libxcb-xlib.so.*. I think.

libX11
Username: BarryK
"Or rather, it used to. I have recompiled libx11 to not use xcb, however libgoffice doesn't know that.

Bingo!
Username: BarryK
"I tried something: [i]# cd /usr/X11R7/lib # ln -s libX11.so.6 libxcb-xlib.so.0 # ln -s libX11.so.6 libxcb.so.1 [/i] ...then abiword worked! This proves that libgoffice doesn't really need libxcb, just thinks it does. This is good, I will continue with this experiment!

More compiled
Username: BarryK
"I have recompiled various packages, where I thought they needed it in the new environment. None of these are version upgrades. [i]geany 0.19.1 gtkdialog4 246 gtksourceview 2.6.2 libglade 2.6.4 notecase 1.9.8 pixman 0.18.4 rox_filer 201012git-patched[/i]

xcb X11 and autotools
Username: technosaurus
"for the packages that it does break adding -Wl,--as-needed to LDFLAGS will normally fix the problem I have previously modified the .pc files in my DEV packages to fix it _more_ properly and put the originals in a separate DEV-static package (or /dev/null) If I actually want static libs I normally do a separate compile with -ffunction-sections -fdata-sections in the CFLAGS anyways (can yield a 50% reduction in binary size later with LDFLAGS=-Wl,--gc-sections) Here is the root of the problem: the .a files need to know all of the dependencies in the . pc file so the linker will know what to link against the .so.* files do not need this info - it was built into the library at link time (see below) [b]objdump -x [file] |grep NEEDED[/b] however when the dependencies are in the .pc file (for the benefit of static libs) they get included in the link and link directly rather than relying on the builtin abilities to find the dependencies this is what causes the breakage on upgrade for many packages there is an easier fix, namely --disable-static (some actually _do_ know better than to do this for shared libraries) this is just another reason to do separate compiles for the static libs... besides there are plenty of static libs in the devx that are unnecessary bloat with the matching shared lib in the main sfs (over 10mb iirc) Long story short, if you edit the Requires in X11.pc before compiling against it, the linker will do the rest. I would rather have a good Makefile or build script than ./configure anyday because of these kinds of idiosyncrasies btw gtk+-2.24.6 is out

xorg path
Username: 01micko
"Hi Barry, please excuse my ignorance! Now.. regarding upgrade from xorg-7.3 to 7.5... is the path the same? That is, is the xorg-7.5 compiled --prefix=/usr/X11R7? Couple of reasons I ask. 1) This may be irrelevant to the path. Nvidia and ATI drivers? Will they work if installed, then a user upgrades Xorg? Probably a stupid question but then same could be asked, will they work after a user has upgraded to xorg-7.5 then installs nvidia/ati drivers? 2) Mavrothal and myself have been working on a universal script to convert any Puppy to the OLPC format/platform. So far the success rate is beaut, especially with Slacko/Lupu/Squeeze Puppies. Wary is only any good on the XO-1, because the [i]geode[/i] driver is ok in xorg-7.3 but [i]openchrome[/i] is deprecated (badly). The new xorg module that works in xorg-7.5+ is [i]chrome[/i]. I tried an upgrade to xorg-7.5 with 5.1.4 and it was a miserable fail.. sorry no details, failed, gave up, my story at the time! (Of course needed dev upgrades too). Also, important to our little script is the path to xorg libs. Just some of my ideas .. :)

Re retire
Username: BarryK
"Yeah, funny kind of retirement hey. I have announced my "retirement" a couple of times. I have tried to take more of a back seat, but I'm still heavily involved. At least the main official Puppy, Lucid, has demonstrated a team working independent of me, and upcoming Slacko etc will continue that. I want to keep working on Woof and Wary, probably for the next year or two. Then, there is a strong likelihood that I really will, finally, retire from Puppy development.

Xorg 7.5 path
Username: BarryK
"Yes, it was compiled with --prefix=/usr/X11R7. You will see in Wary though, that there are lots of symlnks from /usr into /usr/X11R7, so that when compile packages that somehow ignore /usr/X11R7, they will still find what they need and configure/compile ok.

xcb
Username: BarryK
"technosaurus, Thanks for the explanation, I knew that you would have a pretty good idea what is going on with phantom xcb dependencies.

Tags: wary