Bug 555325

Summary: pkg-config file missing "-laudcore"
Product: [Fedora] Fedora Reporter: Milos Jakubicek <xjakub>
Component: audaciousAssignee: Michael Schwendt <bugs.michael>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: atkac, bugs.michael
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://jira.atheme.org/browse/AUD-125
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-15 13:32:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 483025    

Description Milos Jakubicek 2010-01-14 13:30:58 UTC
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')

Comment 1 Michael Schwendt 2010-01-14 14:03:20 UTC
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

Comment 2 Michael Schwendt 2010-01-15 13:32:38 UTC
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.

Comment 3 Milos Jakubicek 2010-01-16 23:00:52 UTC
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.

Comment 4 Milos Jakubicek 2010-01-16 23:01:41 UTC
(just to be precise: I didn't mean *your* answer of course but that one from upstream:)

Comment 5 Michael Schwendt 2010-01-16 23:26:12 UTC
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.

Comment 6 Michael Schwendt 2010-01-17 21:24:08 UTC
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.

Comment 7 Milos Jakubicek 2010-01-17 23:58:30 UTC
(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:(