windres passes on paths incorrectly

[Optiligence]

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

[brisingraerowing]

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)

[Optiligence]

I usually don’t use build folders with spaces so that‘s no issue, but I would like if it worked nonetheless.

[AraHaan]

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).

[Optiligence]

this is still broken though

[Alexpux]

This is not our issue at all. We not recommend to use folders with spaces. Read wiki.

[Alexpux]

It not work under cmd too. But works next variant:

windres -I\""C:/Temp/New folder/\"" -v

[Optiligence]

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.

[Alexpux]

Well you can try to fix windres command line parsing or report it upstream

[mingwandroid]

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).

[AraHaan]

@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/

[till213]

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.

[mati865]

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.

[till213]

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. :)

[mati865]

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).