Deadbeef, Transmission

ttuuxxx has compiled Deadbeef, a music player, and Transmission, a bit-torrent client, in Wary:
http://murga-linux.com/puppy/viewtopic.php?t=65028&start=135

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

DeaDBeef in Wary
Username: session
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?

Re DeadBeef and Xorg 7.5
Username: BarryK
"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.

Re DeadBeef and Xorg 7.5 error message
Username: session
"[code]dlopen error: /usr/X11R7/lib/libxcb-xlib.so.0: undefined symbol: _xcb_lock_io[/code] after loading plugins gtkui.so, hotkeys.so, and shellexec.so

Re DeadBeef
Username: 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.

Re DeadBeef
Username: BarryK
"Hmmm, I wonder if DeadBeef has a '--without-xcb' configure option? Some source pkgs do.

auto* is stupid (re: deadbeef)
Username: technosaurus
"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.

Tags: wary