-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
*windows-default-manifest
package issues
#454
Comments
Steps to reproduce a corrupt Requires MSYS2 with mingw-w64 newer than ~2014 October (possibly also works with built-in mingw 4.9.2 — not tested). Tested with: mingw-w64 5.3.0-2
#include <stdio.h>
__attribute__((dllexport)) int main(void)
{
printf("hello\n");
return 0;
}
1 24 /* RT_MANIFEST */
BEGIN
"<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?>"
"<assembly xmlns=""urn:schemas-microsoft-com:asm.v1"" manifestVersion=""1.0"">"
"</assembly>"
END making sure to have the default manifest package installed:
build:
compress (using UPX 3.91):
It may well indicate an UPX problem, too — one that's surfacing with such an invalid binary. Nevertheless, the duplicate, orphan, default resource is what causes the chain of events. |
This is one of those bugs that requires significant effort to even know which project it belongs to! We can definitely rule out Cygwin (or the msys2-runtime fork) though, it's between UPX and MinGW-w64's GCC/binutils. I'd like to bring it to Kai Teitz's attention but I feel we should spend more time on it first, however I am far too busy. You've done a lot of work on it already, and that's great, so I'm tempted to offer to try to help you to help yourself, if possible ... So, is there anything at all that you need to know about MSYS2 that would allow you further your own investigations? I'm thinking for example things about how to build debug versions of packages and advice about how to debug them in MSYS2? Ask here or jump into IRC (#msys2 on OFTC) if we can be of any use in that regard. I'm thinking the bug surface area is just too large and you seem capable of zero-ing in effectively, so there's probably no one better for the job given your head is exactly in this space. I was going to suggest bringing it up on GCCs bugzilla or sending a mail to MinGW-w64's mailing list, but I think it's a bit to vague at present. |
Thanks @mingwandroid! I'm going to register to GCC Bugzilla and follow-up on it. |
Ok, please keep this issue updated, it certainly looks like a complicated one. UPX always does complicate things. |
I'll definitely update this. Till it gets sorted out throughout the toolchain/UPX (both would take quite some time I reckon), do you see any option to work this around by uninstalling the default manifest packages? I understand they're useful for some apps and most certainly when building MSYS/Cygwin's own binaries, but for user apps in general, it's not always a blessing. |
GCC Bugzilla report submitted: |
@mingwandroid Just read your updated message above. Many thanks for offering your help! I was busy filing the Bugzilla report, which is now finished. It contains some extra bits of information, but it's still difficult to tell which component will be the best candidate for a fix. Maybe multiple. For now, the issue could possibly be avoided from the MSYS2 side by uninstalling the I'm new to
Can you help assessing the two ideas above? [ If none of these is possible, an ugly, but effective hack would be to manually delete all the offending objects — either before starting a build or after each MSYS2 update. ] |
Package information here:
It means assumptions were correct — for some reason the default manifests are being shipped as an inseparable part of gcc. Above files also describe the rest of the included dependencies. |
Patches that enabled default manifests:
|
BTW, if anyone wonders, manifests — speaking about these default ones — serve the purpose to force certain Windows API calls (non-deprecated ones included, like It would be interesting to know the reason behind the decision to apply this automatically to all built binaries. |
Workaround implemented for the time being: |
Wouldn't |
I'm closing this without solution or feedback. |
Sorry I have no time to handle all issues. We need to think how to do it properly |
Thanks for jumping in, no problem to keep it open if there is an interest in this. Thanks! |
…ub.com) * package/mpkg_win_ci.sh * package/mpkg_win_dl.sh % do not bundle upx.exe with the Harbour package. Besides being another maintenance burden, due to some MSYS2/Cygwin decisions, binutils bugs and upx properties, by default, MSYS2-built binaries may not always be UPX-ed. The resolution is stalled for now and will probably take some years to get sorted out. Refs: msys2/MSYS2-packages#454 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 Anyhow, UPX-ing binaries have some drawbacks because the image cannot be mmap-ed and/or loaded on demand and/or shared between processes. It also mangles the content so it's doesn't help transparency. So, unless the binary is executed through the local network from a network share, it's not very useful. Get latest version via MSYS2 pacman -S upx or from: https://fossies.org/windows/misc/upx391w.zip
@vszakats Many thanks for the detailed steps and documentation you've taken so far! I'm having this issue with a project as well (auto-mentioned above), therefore the workaround is also very much appreciated. To answer the question about why the manifesto is embedded by default, it's documented here: https://sourceforge.net/p/mingw-w64/wiki2/default_manifest/ It was rather unfortunate that it auto-links it in, but at least renaming/removing the file is a relatively simple way to workaround the issue. In the meantime, I'll try to look into the patch that was provided at GCC's bugzilla. I have some experience in cross-compiling the whole GCC stack on Linux for Windows, so it should be relatively easy for me to apply the patch and test it on my existing development stack. |
@wyldckat You're welcome and thanks for the link too. Looking forward for your |
UPX release 3.92 (released yesterday) implements a workaround where it allows to override the |
I'm closing this because the Issue on this level now has sufficient workarounds and the root cause got its own (still open) Issue on GCC bugzilla, with a proposed, but untested yet patch. |
Just chiming in to "optimize" some searches to hopefully make this easier to debug for others. While building libcdr and libvisio this very issue caused the build process to fail silently (i.e. no error message at all) while linking Only a non-zero return code of Edit: Also seems to be highly arbitrary. libcdr-0.1.2 failed to build, libcdr-0.1.3 worked (both with mingw64). libvisio-0.1.5 failed when built with mingw64 but succeeded in mingw32. |
Great, thanks for testing. |
Same problem: can't compress with UPX, superfluous data between sections. MSYS2 x64, latest packages. |
@IlyaBizyaev can you test UPX 3.93 (in repo there is 3.91 version)? |
@mati865 Tested, same issue |
This has been confirmed earlier, but the superfluous data is unrelated to the manifests (the subject of this Issue). Likely a different binutils issue. |
How can I disable this default manifest from a build option? I am building a package for Go that allows writing GUI programs, and Go uses gcc for linking C modules. Since I'm not specifying any manifest files in the C modules (intentionally, to allow them to be overridden by users), and due to the way Go links stuff with gcc, the manifest is automatically added to my code (and then linked into code that uses my code). This is a problem because I need to use Common Controls v6, and the embedded manifest means Windows never even looks at any manifest file in the same directory as the executable. Also how does this have no errors when merging two .a files, both specifying manifests? With the way Go builds packages that depend on C modules, two packages will each have their own embedded versions of the manifest. Is there no conflict because they are identical? Does one win out over the other? |
@andlabs: If I remember correctly, this also affects Cygwin, not just MSYS2, as well as cross-compiling on other platforms (e.g. compiling Windows-binaries from Linux). As for the You may want to try and unpack the |
Cygwin is most likely affected, that's where the idea of default manifest originates from. Can't confirm the cross-compiling case though — with mingw-w64 toolchains on macOS (via Homebrew) and Linux, the package responsible for installing the default manifest files does not exist. |
@vszakats Many thanks for the reminder! Indeed, this was implemented on GCC for Cygwin and MSYS2 inherited it. Following up on the mailing list thread you originally mentioned, there is this email that explains what should happened when more than one manifest file exists: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01382.html Mmm... however, it was implemented directly into GCC upstream, so any bug reports for it should still be presented on its bug tracker. |
Er yeah, sorry I meant to say I'll probably just provide a package with a manifest that people can optionally use, assuming the merging facility does indeed work even with |
@wyldckat You're right, the feature to pick up and use a default manifest if present on disk are implemented in the GCC toolchain indeed. (They are only present in MSYS2/Cygwin though.) |
…S2/Mingw32 The issue pertains to MSYS2 adding a default manifest file (default-manifest.o) to the executable The bug is for PC systems with GPU drivers that were not properly supported for Windows 10 systems, like Intel HD Graphics series 1rst and 2nd generations. In those systems, launching a game in ScummVM (built with MSYS2/Mingw) with the OpenGL renderer would cauase the game screen to be a white blank image, and various warnings would be output to the console: eg. "WARNING: GL ERROR: GL_INVALID_ENUM on glTexSubImage2D(0x0DE1, 0, 0, area.top, src.w, area.height(), _glFormat, _glType, src.gere.cpp:167)!" This was due to MSYS2/Mingw builds trying to load the (poorly supported) GPU driver while advertising support for Windows 10 in their embedded default Manifest file. Hence, the GPU driver dll (eg ig4icd64.dll) would be unloaded, causing the bug. More information is available in the following links: https://github.com/pal1000/save-legacy-intel-graphics LWJGL/lwjgl#119 msys2/MSYS2-packages#454 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880
This fixes an OpenGL renderer issue for builds with MSYS2/Mingw64 or MSYS2/Mingw32 The issue pertains to MSYS2 adding a default manifest file (default-manifest.o) to the executable The bug is for PC systems with GPU drivers that were not properly supported for Windows 10 systems, like Intel HD Graphics series 1st and 2nd generations. In those systems, launching a game in ScummVM (built with MSYS2/Mingw) with the OpenGL renderer would cause the game screen to be a white blank image, and various warnings would be output to the console, eg. "WARNING: GL ERROR: GL_INVALID_ENUM on glTexSubImage2D(0x0DE1, 0, 0, area.top, src.w, area.height(), _glFormat, _glType, src.gere.cpp:167)!" This was due to MSYS2/Mingw builds trying to load the (poorly supported) GPU driver while advertising support for Windows 10 in their embedded default Manifest file. Hence, the GPU driver DLL (eg ig4icd64.dll) would be unloaded, causing the bug. More information is available in the following links: https://github.com/pal1000/save-legacy-intel-graphics LWJGL/lwjgl#119 msys2/MSYS2-packages#454 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 Credits to sluicebox for the VS GenerateManifest flag
It is April 2021. I am still running into that Issue that GCC always links against the default-manifest.o and ignores my own Resource File. I have manually deleted the default-manifest.o as LD.exe should not fail to link without that File but it does. Is there finally a GCC/LD/Whatever Flag to prevent calling the default-manifest.o File? Please make this go away! Thank you! |
And is still happening in 2022. I'm trying to build something with a manifest file so that a gtk3 app gets scaled properly when using a factional scale (my eye can't cope with 100% and 200% is huge) and this happens:
on top of the usual (and equally irritating but probably less harmful)
And my manifest appears to be being discarded (I don't know this for sure because I'm new at this, but the effect I'm hoping for isn't happening) |
Can you provide the steps and minimal code example to reproduce your issue? |
ah, sorry, i found out it was a problem in the makefile which was including the compiled rc twice. took some fiddling to find that out. i forgot to update this. |
HI, |
What is the recommended approach when custom manifest is needed like when using comctl32 v6? If I embed yet another resource with RT_MANIFEST, it makes no difference. However, everything works if default-manifest.o is replaced with an empty file. |
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:
upx: test.exe: CantPackException: superfluous data between sections
), which could be worked around by astrip test.exe
command,but which also stripped valid parts off of the internal manifest.)mingw-w64-i686-windows-default-manifest
mingw-w64-x86_64-windows-default-manifest
mingw-w64-cross-windows-default-manifest
(possibly)windows-default-manifest
/mingw32/i686-w64-mingw32/lib/default-manifest.o
/mingw64/x86_64-w64-mingw32/lib/default-manifest.o
/usr/lib/default-manifest.o
Everything considered, it might be a satisfactory solution to detach these
*windows-default-manifest
packages from themingw-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.]
The text was updated successfully, but these errors were encountered: