Closed Bug 571138 Opened 14 years ago Closed 14 years ago

Workaround not having PR_GetLibraryFilePathname

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mwu, Assigned: blassey)

References

Details

Attachments

(3 files, 3 obsolete files)

set ld path from GeckoApp
(deleted), patch
mwu
: review+
Details | Diff | Splinter Review
patch
(deleted), patch
Details | Diff | Splinter Review
load libs from java
(deleted), patch
mwu
: review+
Details | Diff | Splinter Review
Attached patch Hack (obsolete) (deleted) — — Splinter Review
NSS requires PR_GetLibraryFilePathname to load properly.
Attachment #450249 - Flags: review?(ted.mielczarek)
Attached patch patch (obsolete) (deleted) — — Splinter Review
Attachment #450249 - Attachment is obsolete: true
Attachment #451344 - Flags: review?(ted.mielczarek)
Attachment #450249 - Flags: review?(ted.mielczarek)
Attached patch patch (obsolete) (deleted) — — Splinter Review
Attachment #451344 - Attachment is obsolete: true
Attachment #451428 - Flags: review?(ted.mielczarek)
Attachment #451344 - Flags: review?(ted.mielczarek)
Attached patch set ld path from GeckoApp (deleted) — — Splinter Review
Assignee: mwu → blassey.bugs
Attachment #451429 - Flags: review?(mwu)
Attachment #451429 - Flags: review?(mwu) → review+
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?
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.
Attachment #450249 - Attachment is obsolete: false
Attachment #450249 - Flags: review?(ted.mielczarek)
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?
(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.
Attachment #450249 - Flags: review?(ted.mielczarek) → review-
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.
Attachment #451428 - Flags: review?(ted.mielczarek) → review-
Attached patch patch (deleted) — — Splinter Review
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)
Attached patch load libs from java (deleted) — — Splinter Review
this works around the problem by loading the nss libs from java before we start gecko
Attachment #452078 - Flags: review?(mwu)
Comment on attachment 452078 [details] [diff] [review] load libs from java \o/
Attachment #452078 - Flags: review?(mwu) → review+
Attachment #451882 - Flags: review?(ted.mielczarek)
pushed http://hg.mozilla.org/mozilla-central/rev/109784251c6c
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: