Closed Bug 681716 Opened 9 years ago Closed 9 years ago

Sort out glue linking situation on iOS

Categories

(Core :: XPCOM, defect)

ARM
iOS 4
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla9

People

(Reporter: ted, Assigned: ted)

Details

(Whiteboard: [iOS] fixed-in-bs)

Attachments

(1 file, 2 obsolete files)

I currently have this patch in my iOS patch queue. The APIs that nsGlueLinkingOSX relies on are not available on iOS, and the online documentation says their use is "discouraged" and recommends using dlopen[1]. OS X has had dlopen since 10.3, so we can use it there without any problems. The downside of this exact patch is that we'll lose the preloading work that glandium wrote. We can either a) rewrite nsGlueLinkingOSX to use dlopen (probably not hard), or b) merge the OS X preloading code into nsGlueLinkingDlOpen.cpp and hg rm nsGlueLinkingOSX.cpp

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
Attached patch Use dlopen glue on Darwin (obsolete) — Splinter Review
This patch, that I forgot to attach.
Whiteboard: [iOS]
Attached patch Use dlopen glue on Darwin (obsolete) — Splinter Review
Right, and this is the actual patch (I forgot to qrefresh).
Attachment #555475 - Attachment is obsolete: true
(In reply to Ted Mielczarek [:ted, :luser] from comment #0)
> I currently have this patch in my iOS patch queue. The APIs that
> nsGlueLinkingOSX relies on are not available on iOS, and the online
> documentation says their use is "discouraged" and recommends using
> dlopen[1]. OS X has had dlopen since 10.3, so we can use it there without
> any problems. The downside of this exact patch is that we'll lose the
> preloading work that glandium wrote. We can either a) rewrite
> nsGlueLinkingOSX to use dlopen (probably not hard), or b) merge the OS X
> preloading code int nsGlueLinkingDlOpen.cpp and hg rm nsGlueLinkingOSX.cpp
 
I'd go for the latter. You may want to avoid preloading on iOS, though.
I don't think that dlopen works the same way that the MachO APIs do, which is why I had to use these. In particular, the flag NSADDIMAGE_OPTION_MATCH_FILENAME_BY_INSTALLNAME was crucial to the correct functioning of the glue with binary components, given the weirdnesses of install names on Darwin.

Of course, we could just say that binary components are not supported at all on iOS, in which case "whatever works" is fine: but that won't fly for desktop builds.
Note that the NS*Image* APIs have been deprecated as of OS X 10.5, so there's no guarantee they'll continue to work in the future.

Also, I dug into the dyld source, and it looks like dlopen always passes that "match filename by installname" flag as true:
http://opensource.apple.com/source/dyld/dyld-132.13/src/dyldAPIs.cpp
(Search for "void* dlopen", then scroll down and you'll see "context.matchByInstallName = true;".)

That's the dyld in 10.6.8, but I looked at an older version and it was the same.
In lieu of sorting that all out, here's a patch that just makes us use the dlopen glue on iOS, while continuing to use the OS X glue on desktop OS X.
Attachment #555483 - Attachment is obsolete: true
Attachment #555738 - Flags: review?(benjamin)
Attachment #555738 - Flags: review?(benjamin) → review+
http://hg.mozilla.org/mozilla-central/rev/ccc8a52f68b0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.