681716 - Sort out glue linking situation on iOS

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[(not currently active) Ted Mielczarek]

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

Comment 1

[(not currently active) Ted Mielczarek]

Attachment: Use dlopen glue on Darwin

This patch, that I forgot to attach.

Comment 2

[(not currently active) Ted Mielczarek]

Attachment: Use dlopen glue on Darwin

Right, and this is the actual patch (I forgot to qrefresh).

Comment 3

[Mike Hommey [:glandium]]

(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.

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[(not currently active) Ted Mielczarek]

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.

Comment 6

[(not currently active) Ted Mielczarek]

Attachment: use dlopen linking glue on iOS

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.

Comment 7

[(not currently active) Ted Mielczarek]

http://hg.mozilla.org/projects/build-system/rev/ccc8a52f68b0

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/ccc8a52f68b0