Nostalgia struck this morning and I was pining after the wmhdplop and wmforkplop dock apps, from … gosh, more than seven years ago.
That’s them, up in the corner. Yes, they are quite obtrusive. I know.🙄
Dock apps are my few extravagances, and these two are really the only ones that have survived over the years. Imagine my surprise today when the tried-and-true PKGBUILDs out of the AUR spat out ugly little gcc errors instead.
gcc: error: @my_libs@: No such file or directory
This is odd. And what is that “@my_libs@” stuff? I don’t ever recall seeing a gcc error like that before. Of course, I have all the compiling prowess of a dusty brick, but still. …
For once, rather than just yammer mindlessly about it on this site, I put on my deerstalker cap and went investigating.😐
To make a ridiculously long and uninteresting story into a short and only a little more interesting story, the culprit is … imlib2, of all things. Apparently that “@my_libs@” string appears in version 1.4.6 of imlib2, which dates back to around Christmas.
I don’t know what exactly @my_libs@ is supposed to mean there; apparently the packaged imlib-config.in file is some sort of configuration script. It could be stereo instructions for all I know.🙄
I’m all for that. In short, if you build imlib2 from scratch, either with ABS or yaourt or whatever, do this first:
sed -i 's/@my_libs@//' imlib2-config.in
You should end up with an installable version of imlib2 that doesn’t trigger gcc errors when you attempt to build wmhdplop and wmforkplop.😕 Which was the original goal.😀
The resulting package, to the best of my knowledge, is perfectly compatible on every other front, and perhaps even an improvement in that it doesn’t cause problems. I think.😯
I’m debating if this is bug-worthy for the Arch version; it seems like this occurs waaay up the food chain, back to the Enlightenment crew. I’ll at least leave a note on the AUR pages for whoever stumbles past them.😉