Bugzilla

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.dll.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.dll.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we could then use the script as a basis for a more solid continuous integration check that `comsupp.lib` doesn't get linked into `xul.dll` by mistake.

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.dll.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.dll.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we could then use the script as a basis for a more solid continuous integration check that `comsu pp.lib` doesn't get linked into `xul.dll` by mistake (or just check that in `xul.dll.pdb` if it's always produced, I don't know).

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.dll.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.dll.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we could then add a continuous integration check that `comsupp.lib` doesn't get linked into `xul.dll` by mistake.

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.dll.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.dll.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we could then add a continuous integration check that `comsupp.lib` doesn't get statically linked into `xul.dll` by mistake.

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.dll.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.dll.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we should add a continuous integration check that `comsupp.lib` doesn't get statically linked into `xul.dll` by mistake.

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we should add a continuous integration check that `comsupp.lib` doesn't get statically linked into `xul.dll` by mistake.

So there are two ways to know if `comsupp.lib` was statically linked into `xul.dll` for a given version of Firefox you have at hand:

- if you have the `xul.pdb` file with debug symbols, that's as simple as checking if `grep vtMissing xul.pdb` gives a match;
- if you don't, I wrote [a quick and dirty script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py) that will give you a probable answer for x64 builds, and you'll need to `pip3 install pefile` to use it.

Here is the script's output for Release and Nightly:

```
$ python3 comsuppdetector.py /c/Program\ Files/Mozilla\ Firefox/xul.dll
No potential `dynamic_atexit_destructor_for_'vtMissing'' was found.
It is safe to assume that comsupp.lib was not statically linked into 'C:/Program Files/Mozilla Firefox/xul.dll'.
$ python3 comsuppdetector.py /c/Program\ Files/Firefox\ Nightly/xul.dll
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854a8940, vtMissing would be at 0x1863a6008.
It is likely that comsupp.lib was statically linked into 'C:/Program Files/Firefox Nightly/xul.dll'.
```

So it seems that a recent change indeed makes `comsupp.lib` to be statically linked into `xul.dll`, leading to the current situation. [:rkraesig] mentioned that `comsupp.lib` is linked implicitly when including `comdef.h`, so by mixing this information with the script I should be able to find the culprit commit. We can then determine whether there was a good reason for the linking and we should keep it, or there was no good reason and we should add a continuous integration check that `comsupp.lib` doesn't get statically linked into `xul.dll` by mistake.