Closed Bug 358565 Opened 15 years ago Closed 15 years ago
_386 _PC32 relocations in libpipnss .so when building on FC6
When building on Fedora Core 6 (where our system wrappers stuff works, and where the big gcc visibility bug is fixed), SELinux prevents libpipnss.so from loading due to these relocations: 0006f868 R_386_PC32 PK11_GetBestSlot 0006f8a1 R_386_PC32 PK11_ImportSymKey 0006f8b0 R_386_PC32 PK11_FreeSlot 0006feaf R_386_PC32 PK11_DeleteTokenPrivateKey 0006fec7 R_386_PC32 PK11_DeleteTokenPublicKey 0006fedf R_386_PC32 PK11_FreeSymKey (See also similar bug 358558 and bug 358559. The patch will probably end up being similar.) This doesn't prevent the browser from starting, like those bugs do, but it prevents https, etc., from working.
The bad relocations are in the functions: nsKeyObjectFactory::KeyFromString nsKeyObject::CleanUp
Ah, we have a system wrapper for pk11func.h but not for pk11pub.h (which is included by nsKeyModule.h).
Note that pk11func.h is now just a stub header that includes pk11pub.h and pk11priv.h, with the comment that it was an old header with a mix of public and private functions -- now separated. So pk11pub.h is presumably considered a better header to include than pk11func.h.
Checked in to trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 243942 [details] [diff] [review] patch This is a very low risk patch that will, along with the patches to bug 358558 and bug 358559: * allow Linux distros to take advantage of performance optimizations (prelinking) and security improvements (SELinux) * make it easier for developers to build on new distributions like Fedora Core 6
Attachment #243942 - Flags: approval220.127.116.11?
David, thanks for fixing building on Fedora. cc'ing Bob and Wan-Teh FYI
Note that this is not the only such bug -- I should in fact probably file a meta-bug to track these issues since I'm starting to lose track. (It'll get added to the "blocks" list above once I do.)
Comment on attachment 243942 [details] [diff] [review] patch approved for 1.8 branch, a=dveditz for drivers Why are you only requesting 1.8.1 approval when the other two also requested 1.8.0 branch approval?
Attachment #243942 - Flags: approval18.104.22.168? → approval22.214.171.124+
Because the change causing it was not on the 1.8.0 branch -- it was in the PSM changes made for the anti-phishing stuff.
Checked in to MOZILLA_1_8_BRANCH.
You need to log in before you can comment on or make changes to this bug.