Rather than hardcoding them individually, so that it's all in one place
when adding new ones.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
The window itself is not a DOM node, so this is perfectly normal to fail
here. In fact, we weren't dispatching any gecko events sent to the window.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Replacing symt_get_inlinesite_depth() with SymAddrIncludeInlineTrace()
as they look very (very) similar.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Fix a couple of failures on Windows 10:
- it seems that attributes are no longer accessible by name after
shared deletion
- really looks like that shared deletion is now marked at object's
name hierarchy level (see error codes have changed too)
So,
- replace tests based on GetFileAttribute with testing presence of
pending deletion flag (FileStandardInformation)
- add Win10 error codes (and mark the Win7/8 ones as broken)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
In PDB debug information, compiland's pathname is stored twice:
- both refer to the same file, but with variations in path handling
(eg: one could be foo1\foo2\bar.obj and the other
foo1\deadbeef\..\foo2\bar.obj)
Use same pathname string as native when storing compiland's pathname
(it eases comparison of dumps between the two).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
This allows 32-bit packages to be found when the user has specified
PKG_CONFIG_PATH for some other reason.
This also mirrors the way e.g. i686-linux-gnu-pkg-config is implemented on
Debian, and possibly other distributions as well.
This also prevents 64-bit .pc files from being found. This was originally
intended as a benefit [1], but can contribute to misdetection of headers which
are not actually multiarch (e.g. GStreamer, although at the time that [1] was
written that was a preëxisting problem). In general a distribution which
provides .pc files for one architecture should be expected to provide them for
any architecture that it actually provides libraries for; even if that was not
true of Debian in 2017, it is now. I moreover assert it is better to fail to
find a present library than to incorrectly find the wrong one.
Note that we can't easily use i686-linux-gnu-pkg-config, as would otherwise be
preferable, for reasons also described in [1].
[1] https://www.winehq.org/pipermail/wine-devel/2017-June/118002.html
