Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 204262 - glib-sharp.pc file broken on x86_64
glib-sharp.pc file broken on x86_64
Product: Fedora
Classification: Fedora
Component: gtk-sharp2 (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Depends On:
  Show dependency treegraph
Reported: 2006-08-27 17:42 EDT by Paul F. Johnson
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-30 19:23:25 EDT
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 17:42 EDT, Paul F. Johnson
no flags Details | Diff

  None (edit)
Description Paul F. Johnson 2006-08-27 17:42:13 EDT
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 17:42:13 EDT
Created attachment 135016 [details]
glib-sharp.pc.in patch
Comment 2 Alexander Larsson 2006-08-28 04:40:59 EDT
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 15:15:03 EDT
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 03:31:04 EDT
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 04:32:09 EDT
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 03:58:07 EDT
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 19:23:25 EDT
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.