Skip to content

*windows-default-manifest package issues #454

Closed
@vszakats

Description

@vszakats

Hi,

Since this patch, when using MSYS2/mingw-w64, a default Windows manifest is unconditionally added to any linked application if that default resource object file is found.

This causes issues:

  • If a user's build process already sets its own manifest, the resulting binary will be corrupted. (with varying consequences — I got an UPX error message (upx: test.exe: CantPackException: superfluous data between sections), which could be worked around by a strip test.exe command, but which also stripped valid parts off of the internal manifest.)
  • User may want to override the default manifest for various reasons, so a forced system default may not be desired at all times.
  • User cannot override/drop the default manifest using a build-time option. (AFAICS)
  • User may uninstall the related package, but that fails if it was installed via a package group (?) (as seems to be the case f.e. in AppVeyor's default MSYS2 installation), which also appears to be the natural and recommended way of installing mingw-w64. Uninstall failure here:
$ pacman -Suy
[...]
$ pacman -Rs mingw-w64-x86_64-windows-default-manifest
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: mingw-w64-x86_64-gcc: removing mingw-w64-x86_64-windows-default-manifest breaks dependency 'mingw-w64-x86_64-windows-default-manifest'
  • Uninstalling these components also means to alter the system state, which may badly interact with other projects that might actually find a default manifest useful (or are built to rely on it):
    • mingw-w64-i686-windows-default-manifest
    • mingw-w64-x86_64-windows-default-manifest
    • mingw-w64-cross-windows-default-manifest (possibly)
    • windows-default-manifest
  • Manually deleting related files is very hacky and also difficult to maintain. It may also not work on systems where the build process has no write access to system files (i.e. Unix cross-builds):
    • /mingw32/i686-w64-mingw32/lib/default-manifest.o
    • /mingw64/x86_64-w64-mingw32/lib/default-manifest.o
    • /usr/lib/default-manifest.o
  • Separately downloaded (non-MSYS2) mingw-w64 builds don't have this issue, because they are missing the default manifest component.

Everything considered, it might be a satisfactory solution to detach these *windows-default-manifest packages from the mingw-w64-{x86_64,i686}-toolchain package group (or whichever groups they are part of), and let users decide to install it or not. (I'm quite in the dark with pacman packaging details, and couldn't so far find more information about it.)

Overall, the goal would be to keep using existing, custom manifests and disable automatic linkage of any default ones. What would be the best/recommended way to achieve this goal?

[Sorry if this is the wrong place to report this. I'm not exactly sure if this is an MSYS2/Cygwin/mingw-w64 packaging issue, an installation issue (?), or a mingw-w64 toolchain issue. For sure it also involves a linker bug though.]

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions