Description of problem: The pkg-config file should contain "-laudcore" for --libs, currently it causes an audacious plugin package to fail. Version-Release number of selected component (if applicable): audacious-devel-2.2-4.fc12.x86_64 How reproducible: see the second-last comment on https://bugzilla.redhat.com/show_bug.cgi?id=483025 (undefined reference to `filename_to_utf8')
Indeed. But I can't tell whether -laudcore is just missing or if the current set of pkgconfig files (audclient.pc and audacious.pc) is just unfinished. The commit log is not clear either. libaudcore is not the only lib that isn't covered by the .pc files. And audacious.pc duplicates everything found in audclient.pc, which is ambiguous. http://jira.atheme.org/browse/AUD-125
As I understand upstream's response, users of audacious.pc shall decide themselves whether they need to add -laudcore and/or any of the other Audacious libraries.
Hm...the answer is quite strange (I'd say that the first sentence contradicts the other one:), but we'll have to live with that, I guess.
(just to be precise: I didn't mean *your* answer of course but that one from upstream:)
No worries. :) libaudcore is optional. As is libaudgui. Most plugins don't need to link with either one. That's why audacious.pc doesn't add them. And as the plugins don't need to link with libaudclient, the upstream change removed that one, too. The pkgconfig file can still be queried for minimum Audacity version. And where the return value of "pkg-config --libs audacious" is evaluated, it is trivial to add -laudcore if necessary. Of course, it isn't ideal. More convenient would be to introduce an audcore.pc (or audacious-core.pc) file that could be queried instead. And the same for libaudgui.
Hmmm, after I had added a comment in the upstream ticket, the developer changed his mind and now added -laudcore to audacious.pc. I have done the same in Rawhide. Not yet in F-12 (as it would break Conky: bug 556317) and require a refreshed koji buildroot override tag. -- Btw, IMMS failed to build only because it links with -z defs (a detail I overlooked), which doesn't permit undefined symbols in object files. This is different from ordinary Audacious plugins. They are built with undefined symbols if they need libaudcore but don't like with it, and that works only because loading them into Audacious at run-time binds them with the current symbol table that includes libaudcore.
(In reply to comment #6) > Hmmm, after I had added a comment in the upstream ticket, the developer changed > his mind and now added -laudcore to audacious.pc. > That's "dealing with upstream"...:) > -- > > Btw, IMMS failed to build only because it links with -z defs (a detail I > overlooked), which doesn't permit undefined symbols in object files. This is > different from ordinary Audacious plugins. They are built with undefined > symbols if they need libaudcore but don't like with it, and that works only > because loading them into Audacious at run-time binds them with the current > symbol table that includes libaudcore. Thanks for point it out, I missed that as well:(