Bug 204262
| Summary: | glib-sharp.pc file broken on x86_64 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul F. Johnson <paul> | ||||
| Component: | gtk-sharp2 | Assignee: | Alexander Larsson <alexl> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-08-30 23:23:25 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: | |||||||
| Attachments: |
|
||||||
|
Description
Paul F. Johnson
2006-08-27 21:42:13 UTC
Created attachment 135016 [details]
glib-sharp.pc.in patch
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:
prefix=${pcfiledir}/../..
exec_prefix=${prefix}
libdir=/usr/lib64
...
Is your package different?
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)-2.8.0.0 and mono(glib-sharp)-2.10.0.0 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! 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. 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? 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? 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.... |