I have uploaded these PETs to the Wary repo at ibiblio.org and they will be offered by the Puppy Package Manager in the next Wary.
Comments:Posted on 7 May 2011, 12:10 by session
DeaDBeef in Wary
DeaDBeef's a great little player; it's good to have a version compiled in Wary.
Anyone else noticed that DeaDBeef doesn't work in Wary with Xorg 7.5?
Posted on 7 May 2011, 13:59 by BarryK
Re DeadBeef and Xorg 7.5
Did you try running 'deadbeef' in a terminal (I presume that's it's name) to see what error message is output?
It would be interesting to see what it doesn't like in Xorg 7.5.
Posted on 8 May 2011, 3:45 by session
Re DeadBeef and Xorg 7.5 error message
dlopen error: /usr/X11R7/lib/libxcb-xlib.so.0: undefined symbol: _xcb_lock_io
after loading plugins gtkui.so, hotkeys.so, and shellexec.so
Posted on 8 May 2011, 8:33 by BarryK
Oh, that accursed xcb!
Generally, apps compiled for an older Xorg do work in a later Xorg, however the xcb developers have upset that as they have broken their API (Application Programming Interface) with various versions of xcb.
I really would like to have compiled Xorg without xcb, but I think that some apps have come to need it.
Unfortunately, I don't know any workaround for this. The only workaround would be to upgrade DeadBeef to a PET compiled for Xorg 7.5.
Posted on 8 May 2011, 8:36 by BarryK
Hmmm, I wonder if DeadBeef has a '--without-xcb' configure option? Some source pkgs do.
Posted on 8 May 2011, 12:58 by technosaurus
auto* is stupid (re: deadbeef)
I almost guarantee that deadbeef is not directly using _xcb_lock_io
This whole situation would be avoided if the stupid configure script didn't use the pkgconfig for every dependency of gtk2 and link to it directly instead of just doing -lgtk-x11-2.0 (or other direct dependencies that aren't gtk2 deps ... for example libstdc++** ) and letting the damn dynamic linker do its job.
**Note libstdc++ is only a dependency of gtk because of the default selection in T2 to the latest version of pango - it still builds fine with pango-1.24.5 and no dependency on libstdc++
I typically remove any excess indirect dependencies from the final link and then copy off that binary before "make install" because it often tries to hijack the build and relink it.
(simply cut and paste the line that builds the binary and remove any -l<*> that aren't necessary for the binary to successfully build)
This prevents future changes to indirect dependencies from making any negative difference such as:
prevents changes in indirect dependencies from breaking binaries so long as the direct dependencies are rebuilt as necessary.
prevents a change in dependent library from causing a drastic slowdown due to looking for symbols in the wrong places (if it is linked directly it will try to look where the hash table says first - which will be wrong every time even if a single character is added to a single string)
decrease the size of the library (each one of those symbols gets defined in a hash table if it is linked directly - causing the hash table to be larger ... if the linker is allowed to link dynamically it doesn't mess with any that aren't directly in the binary)
Anyhow, this was just FYI ... rebuilding just alleviates the symptom, not the cause. I hack up my .pc files in /usr/lib/pkgconfig/ (saving the original in case I _actually_ want to do a static build), but sometimes it still requires some grokking at build time.