Nostalgia struck this morning and I was pining after the wmhdplop and wmforkplop dock apps, from … gosh, more than seven years ago.
If you don’t know what those are, or if you don’t remember, the home pages are here and here, and in action, they look like this:
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. 🙄
But the Linux From Scratch gang, with the electric precision that earned them their reputation, decided that it was best excised from the source code. With extreme prejudice.
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. 😉
One rule of thumb I learned from trying out many years-old code is checking out Gentoo’s patch if I can’t compile on my own when I have no interesting to fix the build scripts or source codes myself. (I’m a Gentoo user)
Sometimes, it’s GCC has changed a lot or toolchain or whatever changes along the way. Anyway, in this case, I don’t know what it is, but Gentoo also has the patch to eliminate that
@my_libs@.Next time, if you don’t go on an epic adventure of fixing the building, then search “gentoo package ” click on the right link » click on “ChangeLog” » click on “Parent Folder” » enter “files” folder » look for related patches.
And according to this comment, it’s fixed in upstream. It probably will be released in next version, so basically do nothing and wait.
Gosh, sometimes I really hate WordPress doesn’t allow visitors to edit their comments when I (keep) forget angle brackets are sanitized when they are not HTML tags, it’s “gentoo package [package_name]”. Sorry for the noise.
No sweat. I’ll try to edit it to show up right.
Thanks for that. I should think to check Gentoo too, since my experience with Gentoo users says they’re a little more attuned to the fine points of software updates. I’ll do better in the future. 😉
Back then a look into the BugTracker could have saved time 😛
https://bugs.archlinux.org/task/39345 Opened: Tuesday, 11 March 2014,
All described there 😉
Although I’m a little astouned that it took a few months until a rebuild with the patch was done.
But nonetheless. Little is more satisfying if you can get something to work
(And little head->desk moments are part of it if someone discovers that the hours spent could have been minutes 😀 )
Indeed, that’s why Gentoo and Arch Linux both provide bug searching link on package pages, but not all users are aware of that.