925093 - use dlopen, dlsym, and dlclose on OS X instead of old, deprecated functions (NSAddImage etc.)

Status: NEW

(Core :: XPCOM, defect)

Description

[Josh Aas]

xpcom/glue/standalone/nsXPCOMGlue.cpp:130:31 [-Wdeprecated-declarations] 'NSAddImage' is deprecated: first deprecated in OS X 10.5
xpcom/glue/standalone/nsXPCOMGlue.cpp:138:9 [-Wdeprecated-declarations] 'NSLinkEditError' is deprecated: first deprecated in OS X 10.5
xpcom/glue/standalone/nsXPCOMGlue.cpp:156:15 [-Wdeprecated-declarations] 'NSLookupSymbolInImage' is deprecated: first deprecated in OS X 10.5
xpcom/glue/standalone/nsXPCOMGlue.cpp:160:13 [-Wdeprecated-declarations] 'NSIsSymbolNameDefined' is deprecated: first deprecated in OS X 10.4
xpcom/glue/standalone/nsXPCOMGlue.cpp:161:19 [-Wdeprecated-declarations] 'NSLookupAndBindSymbol' is deprecated: first deprecated in OS X 10.4
xpcom/glue/standalone/nsXPCOMGlue.cpp:166:24 [-Wdeprecated-declarations] 'NSAddressOfSymbol' is deprecated: first deprecated in OS X 10.5

Comment 1

[Josh Aas]

Attachment: Fix v1.0

OS X didn't support functions like dlopen, dlsym, and dlclose before OS X 10.3. In 10.3 they were added in a compat mode, in 10.4 they were rewritten to be a native part of dyld.

Now we can just use them, same as Linux, and stop using the old deprecated functions.

Comment 2

[Josh Aas]

Try failed on 10.7:

https://tbpl.mozilla.org/?tree=Try&rev=7aea0c552457

No "__ptr_t" type available. I think I just need to ifdef out that code on OS X rather than define __ptr_t, testing a patch now.

Comment 3

[Benjamin Smedberg]

Discussion with josh today on IRC: one of the weird things about mac was install names. The NSADDIMAGE_OPTION_MATCH_FILENAME_BY_INSTALLNAME flag was necessary so that things that load XPCOM from "strange" locations (not Firefox.app/Contents/MacOS) pick up dependent libraries correctly: we load each dependent library explicitly (from dependentlibs.list) and then we assume that dependencies like @executable_path/libxpcom.dylib will resolve even when binary_path is wrong.

Note that there is a bunch of historical context which may no longer apply: we could switch from using @executable_path to @loader_path, which might make most of this problem go away: bug 578692/bug578751. It's also possible that dlopen now applies the FILENAME_BY_INSTALLNAME logic by default (I'm certain that it didn't in MacOS 10.3).

Unfortauntely I don't think any of this is currently covered by automated testing, although the webapprt stuff is the best place to look.