NS_XPCOM_LIBRARY_FILE might not always reflect reality

NEW
Unassigned

Status

()

Core
XPCOM
2 years ago
2 years ago

People

(Reporter: aklotz, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox47 affected)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
Blocks: 1204682
(Reporter)

Comment 2

2 years ago
Created attachment 8728123 [details]
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/
Attachment #8728123 - Flags: review?(nfroyd)
(Reporter)

Comment 3

2 years ago
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/
(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.
Flags: needinfo?(aklotz)
(Reporter)

Comment 5

2 years ago
(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.
Flags: needinfo?(aklotz)
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
Attachment #8728123 - Flags: review?(nfroyd)
You need to log in before you can comment on or make changes to this bug.