MINGW-packages
MINGW-packages copied to clipboard
msys2
windres passes on paths incorrectly
Include directories with spaces don’t work with windres:
% windres -I"C:/New folder/" -v
gcc: error: folder/: No such file or directory
Using `D:\msys64\mingw64\bin\gcc -E -xc -DRC_INVOKED -IC:/New\ folder/ -'
Using popen to read preprocessor output
D:\msys64\mingw64\bin\windres.exe: preprocessing failed.
% windres -IC:/New\ folder -v
gcc: error: folder: No such file or directory
Using `D:\msys64\mingw64\bin\gcc -E -xc -DRC_INVOKED -IC:/New\ folder -'
Using popen to read preprocessor output
D:\msys64\mingw64\bin\windres.exe: preprocessing failed.
whereas the supposedly used gcc command works on its own:
% echo "#warning test" | gcc -E -xc -DRC_INVOKED -IC:/New\ folder -
<stdin>:1:2: warning: #warning test [-Wcpp]
#1 "<stdin>"
#1 "<built-in>"
#1 "<command-line>"
#1 "<stdin>"
maybe #534 was the same issue
That's the exact same issue I had. It looks like it comes and goes every so often. I don't think I had spaces in the path, but the path handling in Windres might be broken.
As a quick workaround, try the option to use a temporary file (I don't remember what it is called)
I usually don’t use build folders with spaces so that‘s no issue, but I would like if it worked nonetheless.
Sounds like my issue where on MingW and in cygwin it produces an Error when processing any resource script files. Especially this one:
// Microsoft Visual C++ generated resource script.
//
#include "resource.hpp"
#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#ifndef __CYGWIN__
#include "winres.h"
#else
#include <windres.h>
#endif
/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
// English (United States) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)
#ifdef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// TEXTINCLUDE
//
1 TEXTINCLUDE
BEGIN
"resource.hpp\0"
END
2 TEXTINCLUDE
BEGIN
"#include ""winres.h""\r\n"
"\0"
END
3 TEXTINCLUDE
BEGIN
"\r\n"
"\0"
END
#endif // APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Version
//
VS_VERSION_INFO VERSIONINFO
FILEVERSION 0,15,0,0
PRODUCTVERSION 0,15,0,0
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS 0x1L
#else
FILEFLAGS 0x0L
#endif
FILEOS 0x40004L
FILETYPE 0x2L
FILESUBTYPE 0x0L
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904b0"
BEGIN
VALUE "CompanyName", "AraHaan"
VALUE "FileDescription", "bin2c Conversion Tool."
VALUE "FileVersion", "0.15.0"
VALUE "InternalName", "bin2c Conversion Tool"
VALUE "LegalCopyright", "Copyright © 2016 - 2017"
VALUE "OriginalFilename", "bin2c.exe"
VALUE "ProductName", "bin2c Conversion Tool"
VALUE "ProductVersion", "0.15.0"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1200
END
END
/////////////////////////////////////////////////////////////////////////////
//
// Icon
//
// Icon with lowest ID value placed first to ensure application icon
// remains consistent on all systems.
IDI_ICON1 ICON "icons\\Windows\\bin2c.ico"
#endif // English (United States) resources
/////////////////////////////////////////////////////////////////////////////
#ifndef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 3 resource.
//
/////////////////////////////////////////////////////////////////////////////
#endif // not APSTUDIO_INVOKED
Note the __CYGWIN__ block to get if windres is being used (for now).
This is not our issue at all. We not recommend to use folders with spaces. Read wiki.
It not work under cmd too. But works next variant:
windres -I\""C:/Temp/New folder/\"" -v
Well it’s an issue here because it’s basically one of several equal binary distributions of binutils. It works fine with the Arch Linux package.
It’s interesting to see that it works with a double escape (i’m surprised that it seems to be irrelevant where the backslashes are placed), although i’m sure it’s not expected to fix i.e. CMake this way just to workaround this issue.
I’m not a fan of arbitrary restrictions and windres seems to be the only culprit regarding this when building a complex Qt application with CMake.
spaces in paths is a bad idea esp on Linux-y setups, gnu make cannot handle them for starters and there's never been an occasion whether I couldn't avoid them. I acknowledge there are some heavily locked down installations where the user name contains a space and everywhere else is off limits but this is very rare and there are folders without spaces that users can install applications into even in most of those locked down scenarios.
Reporting upstream and fixing would be good but for me life's too short to fix easily avoidable issues that cause problems in many parts of our ecosystem (as it would on any linux distro if you attempted to use spaces in paths when building software).
@wingwandroid I had this problem on my bin2c (resource file posted above) and that project does not use any spaces at all. https://github.com/AraHaan/bin2c/
Hello there,
I just stumbled over this very same issue (in the context of compiling some Qt application with MinGW).
What exactly do you mean "read the Wiki"? What are you trying to imply when you say "We not recommend to use folders with spaces."?
People LOVE spaces. E.g. most people's names have spaces in them (and so do the corresponding user folders on Windows hint hint).
We are not in the 90ies anymore. Heck I expect emoji support in my file paths. So what you you mean with "spaces in paths is a bad idea esp on Linux-y setups" ;)
I want space. I need space.
So is this issue with windres.exe ever going to be resolved? Is it already resolved (I am still using MinGW that comes out of the box with Qt 5.12.15 on Windows)? On Windows, notabene, so not sure why Linux is mentioned at all here, and even there I'd disagree with "spaces are not recommended" these days.
So is this issue with windres.exe ever going to be resolved? Is it already resolved (I am still using MinGW that comes out of the box with Qt 5.12.15 on Windows)?
We track here issues with packaging of MSYS2 packages, you should the bug to Qt or Binutils.
So is this issue with windres.exe ever going to be resolved? Is it already resolved (I am still using MinGW that comes out of the box with Qt 5.12.15 on Windows)?
We track here issues with packaging of MSYS2 packages, you should the bug to Qt or Binutils.
Yes. I know that. But the issue is in one of the MSYS2 tools, as reported in this very issue. And I just ran into the same issue.
The fact that I am using Qt is just pure coincidence and was merely meant to give you some indication about which (older) MSYS version I am using, and hence my question is:
Has this issue with the Windows resource compiler been fixed with a recent version of MSYS (again, I am not specifically asking about the MSYS version that comes standard with Qt, for me Qt 6.x in the future)? Because if not (and according to this issue it still seems to be unresolved) +1 from me to finally fix all „paths with spaces“ issue in 2022. :)
Yes. I know that. But the issue is in one of the MSYS2 tools, as reported in this very issue. And I just ran into the same issue.
It is not exactly MSYS2 issue but one of shipped packages issue. If upstream fixes it we will happily backport and distribute the fix but it's unlikely to get fixed by us.
Reporting it here is the same as reporting at Qt, we only ship the tool. If you want to get it fixed you should contact the tools creators (Binutils project in this case).