Bug 204262 - glib-sharp.pc file broken on x86_64
Summary: glib-sharp.pc file broken on x86_64
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk-sharp2   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-08-27 21:42 UTC by Paul F. Johnson
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-30 23:23:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
glib-sharp.pc.in patch (297 bytes, patch)
2006-08-27 21:42 UTC, Paul F. Johnson
no flags Details | Diff

Description Paul F. Johnson 2006-08-27 21:42:13 UTC
Description of problem:
Minor fault, it's pointing to /usr/lib

Version-Release number of selected component (if applicable):

Additional info:
Patch file attached.

It just patches the glib-sharp.pc.in to point to the correct directory. This
should also fix the problem with banshee

Comment 1 Paul F. Johnson 2006-08-27 21:42:13 UTC
Created attachment 135016 [details]
glib-sharp.pc.in patch

Comment 2 Alexander Larsson 2006-08-28 08:40:59 UTC
I don't understand.
gtk-sharp2 2.10.0 has a "gtk-sharp-2.9.0-libdir.patch" patch that already has a
change like that in it. Extracting the glib-sharp.pc file from 
gtk-sharp2-devel-2.10.0-1.fc6.x86_64.rpm gives:


Is your package different?

Comment 3 Paul F. Johnson 2006-08-28 19:15:03 UTC
It looks like something has gone wrong with the update from the pre lib64
corrected version and the current version. What it looks like is that when the
lib64 fixes were applied and the yum update performed, the old version
(glibc-2.8) remained in /usr/lib instead of being removed.

On my 64 bit box, I have a glib-sharp-2.0.pc in both /usr/lib and /usr/lib64
pkgconfig directories. The only way this can have happened is the new version
didn't splat the old version. It would explain why Banshee drags in both
mono(glib-sharp)- and mono(glib-sharp)-

As to the patch, it seems that my build sys didn't like it and would just ignore
it totally when I tried to build, however, the when I applied the patch from #1,
it did work. Bizarre!

Comment 4 Alexander Larsson 2006-08-29 07:31:04 UTC
Maybe you had edited the old .pc file or something?

The Banshee issue is something else. A Banshee dependency (ipod something)
wasn't rebuilt, and the build copied that dll into the banshee package, which
caused the glib 2.8 dependency in the banshee package.

Comment 5 Paul F. Johnson 2006-08-29 08:32:09 UTC
Nope, I tend not to mess with .pc files for exactly this reason.

Can I assume that as I'm using x86_64 that I can just wipe the 2.8 version in
/usr/lib/mono/gac and the associated pc file?

Comment 6 Alexander Larsson 2006-08-30 07:58:07 UTC
Actually, maybe you used yum to upgrade and thus got both the 32bit and 64bit
versions of the devel package.

Why is the /usr/lib/pkgconfig directory used at all though, do you have a 32bit
version of /usr/bin/pkg-config?

Comment 7 Paul F. Johnson 2006-08-30 23:23:25 UTC
No, 64 bit only pkgconfig. It looks like the problem may have been that I used
to compile mono myself and that's screwed things up. I've now hosed my system
and reinstalled the lot. Seems to be okay now. Well, mostly....

Note You need to log in before you can comment on or make changes to this bug.