1253727 - NS_XPCOM_LIBRARY_FILE might not always reflect reality

Status: NEW

(Core :: XPCOM, defect)

Description

[(No longer employed by Mozilla) Aaron Klotz]

Since bug 671564, it has been based on NS_GRE_DIR. This might not be the case, however, if dependentlibs.list points elsewhere.

Normally this is not an issue, but it is for gtests where this can happen.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=172a1f193ac0

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: MozReview Request: Bug 1253727: Derive NS_XPCOM_LIBRARY_FILE from the actual location of the loaded library; r?froydnj

Review commit: https://reviewboard.mozilla.org/r/38805/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/38805/

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8728123 [details]
MozReview Request: Bug 1253727: Derive NS_XPCOM_LIBRARY_FILE from the actual location of the loaded library; r?froydnj

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/38805/diff/1-2/

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #0)
> Since bug 671564, it has been based on NS_GRE_DIR. This might not be the
> case, however, if dependentlibs.list points elsewhere.
> 
> Normally this is not an issue, but it is for gtests where this can happen.

Can you elaborate on this?  I am too dense to understand what the problem is, and the blocked bug does not provide any enlightenment.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Nathan Froyd [:froydnj] from comment #4)
> Can you elaborate on this?  I am too dense to understand what the problem
> is, and the blocked bug does not provide any enlightenment.

xul.dll and other dependent libraries are loaded by XPCOM glue here:
https://dxr.mozilla.org/mozilla-central/source/xpcom/glue/standalone/nsXPCOMGlue.cpp#343

We iterate through dependentlibs.list and dynamically load each line.
In the case of gtests, dependentlibs.list points to a different xul.dll (ie, the gtest variant). With the status quo, NS_XPCOM_LIBRARY_FILE doesn't reflect a xul.dll that is in a different location from the default.

Comment 6

[Nathan Froyd [:froydnj]]

Comment on attachment 8728123 [details]
MozReview Request: Bug 1253727: Derive NS_XPCOM_LIBRARY_FILE from the actual location of the loaded library; r?froydnj

https://reviewboard.mozilla.org/r/38805/#review35895

I think with the change below, you don't need a separate LibPath file; the code is short enough to be inlined directly into XPCOM init.

::: xpcom/build/LibPath.cpp:31
(Diff revision 2)
> +#if defined(XP_WIN)

I think you can avoid all the ifdeffery here by using PR_GetLibraryFilePathname(XUL_DLL, &appropriate_function), similar to FFVPXRuntimeLinker::Init:

http://mxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp#51