Closed Bug 1656141 Opened 5 years ago Closed 5 years ago

Stop using MT to insert manifests in binaries

Categories

(Firefox Build System :: General, task)

task

Tracking

(firefox81 fixed)

RESOLVED FIXED
81 Branch
Tracking Status
firefox81 --- fixed

People

(Reporter: glandium, Assigned: glandium)

References

(Blocks 1 open bug, Regressed 1 open bug)

Details

Attachments

(9 files, 1 obsolete file)

There are essentially 2 ways the build system currently builds manifests into binaries:

  • through a reference to the manifest in a .rc file
  • through calling mt for manifest files matching the name of the binary with the .manifest suffix.

The interesting thing with this strategy is that in some cases, like mozglue.dll, firefox.exe, xpcshell.exe, etc., we actually do both.

There is actually a third way to handle this, which is to pass the right flags to link.exe (lld-link.exe), which also avoids requiring mt (which is good, because we're currently requiring MSVC's mt and for cross builds have to use wine, and llvm-mt doesn't support what we use mt for).

Uniformization is probably too much for now.

Summary: Uniformize how manifests are built into binaries → Simplify how manifests are built into binaries
Summary: Simplify how manifests are built into binaries → Stop using MT to insert manifests in binaries

It was only ever set to the same value as its default, except in
comm-central, where it is unset, but in directories that now don't link
anything (they did back when binary components were a thing).

There are several things going on here:

  • Replace the use of MT post-linking to passing the same manifest
    manually to the linker. While we passed a resource ID to MT (1 for
    programs, 2 for libraries), these values are the default when using
    -MANIFEST:EMBED, so we just skip giving an ID.
  • At the same time, add an explicit dependency on the manifest for the
    link, which removes the need for EXTRA_DEPS related to manifests.
  • The linker actually doesn't like when a resource file sets a manifest
    with the same ID as the manifest it's given, so we need to remove
    the reference to the manifest in those resource files.
  • In some cases, the reference to the manifest was the only thing in the
    resource file. In practice that means we were adding the manifest
    through the resource file and then re-adding it with MT. We're now
    only adding it via the linker.
  • In the case of updater.exe.manifest, because we're using the file in
    two places, and only for one of them the link rules would find the
    manifest, and because both places use the same resource file, and it
    would be confusing if one place had a manifest defined in the
    resource file and one not, rename the resource file so that it's not
    picked up by the link rule.
  • In the case of DefaultBrowserAgent, the manifest file didn't match the
    program name, so it required extra manual work, and by renaming it, we
    simplify things a little.

Ideally, the manifests would be declared in moz.build, but that
complicates things for cases like TestDllInterceptor, where there are
multiple binaries in the same directory, but only one of them needs the
manifest. This keeps the status quo of getting the manifest
automatically from the source directory, while simplifying things
(slightly), and more importantly, removing the use of MT, which, in
cross-builds, required wrapping with wine.

Depends on: 1116553
Blocks: 1537703

RCFILE is only actually used when the moz.build that contains it defines
a binary, which is not the case for dav1d, which ends up in gkmedias.dll.
Which also means that moving the definition to gkmedias would also not
make sense, since all dav1d.rc does is add descriptors to the dll that it
contains dav1d and what version, but gkmedias.dll contains other things
too.

Because while the original perl script was added to add version info
to Windows binaries, it does more and will do even more with upcoming
changes.

The resource file is always generated so being able to configure its name
is not useful. On the other hand, the way things are currently implemented,
the lack of RESFILE also makes RCFILE ignored, which we fix at the same
time.

And remove a spurious RESFILE in widget/windows/moz.build, where no binary
is produced, which means RESFILE had no meaning.

This will allow creating separate res files for e.g. SIMPLE_PROGRAMS.

That was redundant with the manifest being added with MT (although useful
for mingw builds, that don't use MT), but is also now handled by the
automatic creation of rc files.

The build system will add these manifests whether they are referenced
explicitly in theses rc include files or not.

Comment on attachment 9166998 [details]
Bug 1656141 - Remove EXTRA_DEPS now that it is unused.

Revision D85383 was moved to bug 1498414. Setting attachment 9166998 [details] to obsolete.

Attachment #9166998 - Attachment is obsolete: true

We're currently not using the feature, and host programs ought only
to be used during the build, so I don't expect the feature to ever
be necessary.

Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/4b133eda46aa Remove EMBED_MANIFEST_AT. r=froydnj https://hg.mozilla.org/integration/autoland/rev/de8899453150 Remove dav1d.rc. r=achronop https://hg.mozilla.org/integration/autoland/rev/704f28486bda Rename version_win.py to create_rc.py. r=firefox-build-system-reviewers,mhentges,rstewart https://hg.mozilla.org/integration/autoland/rev/29653ea85d49 Remove RESFILE. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/ce6831acb5e3 Create res and rc files based on the name of the binary they are linked into. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/194a994cf9c9 Remove support for manifests on host programs. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/eb450457a9b7 Stop using MT to insert manifests in binaries. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/e43dd57dc61a Remove rc include files that only add a manifest. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/9033b0400339 Remove redundant manifest references in rc include files. r=firefox-build-system-reviewers,rstewart
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/363f9f07a3d4 Remove EMBED_MANIFEST_AT. r=froydnj https://hg.mozilla.org/integration/autoland/rev/c505d45152cb Remove dav1d.rc. r=achronop https://hg.mozilla.org/integration/autoland/rev/dc8c25ba621c Rename version_win.py to create_rc.py. r=firefox-build-system-reviewers,mhentges,rstewart https://hg.mozilla.org/integration/autoland/rev/e6aeae4a0406 Remove RESFILE. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/778d638bc2b5 Create res and rc files based on the name of the binary they are linked into. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/b512bdbba96c Remove support for manifests on host programs. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/2b521f292b35 Stop using MT to insert manifests in binaries. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/d29d863efda9 Remove rc include files that only add a manifest. r=firefox-build-system-reviewers,rstewart https://hg.mozilla.org/integration/autoland/rev/6661b7ac99c4 Remove redundant manifest references in rc include files. r=firefox-build-system-reviewers,rstewart
Regressions: 1657863
Regressions: 1672457
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: