Closed
Bug 571138
Opened 14 years ago
Closed 14 years ago
Workaround not having PR_GetLibraryFilePathname
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mwu, Assigned: blassey)
References
Details
Attachments
(3 files, 3 obsolete files)
1.01 KB,
patch
|
mwu
:
review+
|
Details | Diff | Splinter Review |
1.21 KB,
patch
|
Details | Diff | Splinter Review | |
768 bytes,
patch
|
mwu
:
review+
|
Details | Diff | Splinter Review |
NSS requires PR_GetLibraryFilePathname to load properly.
Attachment #450249 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 1•14 years ago
|
||
Attachment #450249 -
Attachment is obsolete: true
Attachment #451344 -
Flags: review?(ted.mielczarek)
Attachment #450249 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 2•14 years ago
|
||
Attachment #451344 -
Attachment is obsolete: true
Attachment #451428 -
Flags: review?(ted.mielczarek)
Attachment #451344 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 3•14 years ago
|
||
Assignee: mwu → blassey.bugs
Attachment #451429 -
Flags: review?(mwu)
Reporter | ||
Updated•14 years ago
|
Attachment #451429 -
Flags: review?(mwu) → review+
Comment 4•14 years ago
|
||
Comment on attachment 451428 [details] [diff] [review]
patch
I really don't like this, since it's not actually an implementation of this API. Does Android have /proc/self/maps or anything else you could use to actually implement this?
Comment 5•14 years ago
|
||
I just don't think we should be taking an implementation of an API like that into NSPR.
We have /proc/self/maps, but it's not clear whether we can access it or not (permissions are wonky on android). This patch is only needed for NSS to function, and mwu has an alternative that removes nss's use of this function. That might be a good alternative.
Reporter | ||
Updated•14 years ago
|
Attachment #450249 -
Attachment is obsolete: false
Attachment #450249 -
Flags: review?(ted.mielczarek)
Reporter | ||
Comment 7•14 years ago
|
||
Comment on attachment 450249 [details] [diff] [review]
Hack
Here's the alternate hack.
Do either one of these need to do anything special to handle SD-installed apps? Or are libs still in the /data/data location?
Reporter | ||
Comment 9•14 years ago
|
||
(In reply to comment #8)
> Do either one of these need to do anything special to handle SD-installed apps?
> Or are libs still in the /data/data location?
They still remain in /data/data.
Updated•14 years ago
|
Attachment #450249 -
Flags: review?(ted.mielczarek) → review-
Comment 10•14 years ago
|
||
Comment on attachment 450249 [details] [diff] [review]
Hack
mwu,blassey: thanks for the patches.
NSS should function (except for the FIPS mode, which you can
ignore at first) if PR_GetLibraryFilePathname returns NULL.
NSS should have some fallback code to deal with that condition.
I believe the fallback code relies on the shared library search
path. If the fallback code in NSS is not working, we should
fix that. You should not need to add a stub for
PR_GetLibraryFilePathname.
Updated•14 years ago
|
Attachment #451428 -
Flags: review?(ted.mielczarek) → review-
Assignee | ||
Comment 11•14 years ago
|
||
returning null works if we help dlopen find the library
Attachment #450249 -
Attachment is obsolete: true
Attachment #451428 -
Attachment is obsolete: true
Attachment #451882 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 12•14 years ago
|
||
this works around the problem by loading the nss libs from java before we start gecko
Attachment #452078 -
Flags: review?(mwu)
Reporter | ||
Comment 13•14 years ago
|
||
Comment on attachment 452078 [details] [diff] [review]
load libs from java
\o/
Attachment #452078 -
Flags: review?(mwu) → review+
Reporter | ||
Updated•14 years ago
|
Attachment #451882 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 14•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•