Compiling with Clang on Windows fails at libcurl.rc #7765

VitalyVaryvdin · 2021-09-23T11:54:30Z

I did this

Compiling on Windows 10 with Clang 12.0.1. Ninja build files generated by CMake.
Getting error at curl/lib/libcurl.rc.
llvm-rc: error in versioninfo statement (id 1): [build] non-ascii 8-bit codepoint (169) can't occur in a non-unicode string

Removing everything coming after #define RC_VERSION results in successful compilation.

I expected the following

Successful compilation

curl/libcurl version

7.79.1-DEV

operating system

Windows 10.

UPD:
The issue is here VALUE "LegalCopyright", "\xa9 " LIBCURL_COPYRIGHT "\0" /* a9: Copyright symbol */. Removing this results in successful compilation.
To be exact it doesn't like "\xa9 " part.

UPD:
Adding L before the string fixes the issue.
VALUE "LegalCopyright", "\xa9 " LIBCURL_COPYRIGHT "\0" /* a9: Copyright symbol */
Becomes
VALUE "LegalCopyright", L"\xa9 " LIBCURL_COPYRIGHT "\0" /* a9: Copyright symbol */

Copyright symbol is properly displayed in .dll info

Tested under Clang 12.0.1 and MSVC 16.9

The text was updated successfully, but these errors were encountered:

bagder · 2021-09-23T11:57:56Z

Is this perhaps what's needed? It seems it assumes a certain dir tree layout that may not be true

--- a/lib/libcurl.rc
+++ b/lib/libcurl.rc
@@ -18,11 +18,11 @@
  * This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
  * KIND, either express or implied.
  *
  ***************************************************************************/
 #include <winver.h>
-#include "../include/curl/curlver.h"
+#include <curl/curlver.h>
 
 LANGUAGE  0, 0
 
 #define RC_VERSION  LIBCURL_VERSION_MAJOR, LIBCURL_VERSION_MINOR, LIBCURL_VERSION_PATCH, 0

Reported-by: Vitaly Varyvdin Fixes #7765

VitalyVaryvdin · 2021-09-23T12:25:16Z

Nope, doesn't fix the issue.

The issue is here VALUE "LegalCopyright", "\xa9 " LIBCURL_COPYRIGHT "\0" /* a9: Copyright symbol */. Removing this results in successful compilation.

To be exact it doesn't like "\xa9 " part.

bagder · 2021-09-23T12:34:13Z

Ok, that's beyond me. @vszakats, any idea?

VitalyVaryvdin · 2021-09-23T12:45:47Z

Not sure if that's correct way to fix that but adding L before the string fixes the issue.

VALUE "LegalCopyright", "\xa9 " LIBCURL_COPYRIGHT "\0" /* a9: Copyright symbol */
Becomes
VALUE "LegalCopyright", L"\xa9 " LIBCURL_COPYRIGHT "\0" /* a9: Copyright symbol */

Copyright symbol is properly displayed in .dll info

Upd: works under MSVC 16.9 as well

vszakats · 2021-09-23T18:55:13Z

Codepage requirements/expectations of various compilers and of Windows resource files in general are generally mysterious, so what about replacing that copyright symbol with: (c)? /cc @bagder

Prefixing with L looks interesting, though I have no clue why it works and how portable that is.

UPDATE: L also fixes it in my (non-Windows) LLVM/clang 12.0.1 + mingw-w64 env with command: x86_64-w64-mingw32-windres -c65001. Another thing to try is a literal © and/or the -c65001 (or /C 65001) option.

VitalyVaryvdin · 2021-09-23T21:25:41Z

According to https://docs.microsoft.com/en-us/windows/win32/menurc/stringtable-resource

To encode Unicode characters, use an "L" followed by the Unicode characters enclosed by quotes. See the Examples section for an example.

IDS_RUSSIANSTRING L"\x0421\x043f\x0440\x0430\x0432\x043a\x0430"

I might assume this being pretty portable and common practice.

vszakats · 2021-09-24T00:02:16Z

@VitalyVaryvdin Thanks for the link! It looks good to me. This method may even make any -c codepage options unnecessary.

bagder · 2021-09-24T08:50:20Z

I personally wouldn't mind using the ascii (C) version either. Whatever makes this work better.

VitalyVaryvdin · 2021-09-24T18:56:53Z

You're welcome!

Using (C) would probably be better option, since it presumable would never bring any issues.

Reported-by: Vitaly Varyvdin Assisted-by: Viktor Szakats Fixes #7765

dfandrich · 2021-09-25T06:37:05Z

IANAL, but my understanding is that (C) does not have the same legal meaning as the copyright symbol © in some jurisdictions. If the word "Copyright" exists as well, it's probably fine.

vszakats · 2021-09-25T09:42:50Z

So the options are:

Replacing \xa9 with Copyright (C)
Prefixing current string with L
Adding -c65001 option to all resource compiler invocations (this is suppored by clang/msvc/mingw/pocc/icc/bcc), indicating UTF-8 strings in the .rc input. (and possibly change \xa9 to © in libcurl.rc)

I think the third option gives the most future-proofing (meaning: any future UTF-8 string will continue to work there without further issues), but it is also the one requiring the most work.
Prefixing with L is nice and light, but I'm not sure how to apply it to non-literal strings (ones coming via macros.)
Avoiding UTF-8 is the most risk-averse with the cost of a longer and uglier-looking text and no provisions for any future UTF-8 text.

This adds the flag for the Makefile.m32 build-system:

diff --git a/docs/examples/Makefile.m32 b/docs/examples/Makefile.m32
index 45ec8679c..261dc03be 100644
--- a/docs/examples/Makefile.m32
+++ b/docs/examples/Makefile.m32
@@ -118,7 +118,7 @@ CFLAGS += -fno-strict-aliasing
 # comment LDFLAGS below to keep debug info
 LDFLAGS = $(CURL_LDFLAG_EXTRAS) $(CURL_LDFLAG_EXTRAS_EXE) -s
 RC = $(CROSSPREFIX)windres
-RCFLAGS = --include-dir=$(PROOT)/include -O coff
+RCFLAGS = --include-dir=$(PROOT)/include -O coff -c65001
 
 # Set environment var ARCH to your architecture to override autodetection.
 ifndef ARCH
diff --git a/lib/Makefile.m32 b/lib/Makefile.m32
index 9f1f5963d..0cd903e61 100644
--- a/lib/Makefile.m32
+++ b/lib/Makefile.m32
@@ -115,7 +115,7 @@ LDFLAGS = $(CURL_LDFLAG_EXTRAS) $(CURL_LDFLAG_EXTRAS_DLL) -s
 AR = $(CURL_AR)
 RANLIB = $(CURL_RANLIB)
 RC = $(CROSSPREFIX)windres
-RCFLAGS = --include-dir=$(PROOT)/include -DDEBUGBUILD=0 -O coff
+RCFLAGS = --include-dir=$(PROOT)/include -DDEBUGBUILD=0 -O coff -c65001
 STRIP   = $(CROSSPREFIX)strip -g
 
 # Set environment var ARCH to your architecture to override autodetection.
diff --git a/src/Makefile.m32 b/src/Makefile.m32
index 380d264e7..23afbe308 100644
--- a/src/Makefile.m32
+++ b/src/Makefile.m32
@@ -119,7 +119,7 @@ CFLAGS += -fno-strict-aliasing
 LDFLAGS = $(CURL_LDFLAG_EXTRAS) $(CURL_LDFLAG_EXTRAS_EXE) -s
 AR = $(CURL_AR)
 RC = $(CROSSPREFIX)windres
-RCFLAGS = --include-dir=$(PROOT)/include -O coff -DCURL_EMBED_MANIFEST
+RCFLAGS = --include-dir=$(PROOT)/include -O coff -c65001 -DCURL_EMBED_MANIFEST
 STRIP   = $(CROSSPREFIX)strip -g
 
 # We may need these someday

VitalyVaryvdin · 2021-09-25T09:54:03Z

The symbol is widely recognized but, under the Berne Convention, is no longer required in most nations to assert a new copyright.
The majority of nations now belong to Berne, and thus do not require copyright notices to obtain copyright.

The symbol itself was just an alternative to "Copyright" word in the documents. So probably going with Copyright (C) or even plain Copyright ... is the most elegant solution.

bagder · 2021-09-25T14:08:24Z

"Copyright (C)" is what we use in hundreds of sources files already so it should be fine I think.

gvanem · 2021-09-25T14:46:57Z

To be exact it doesn't like "\xa9 " part.

I assume llvm-rc is the default selection done by CMake. But could it not use rc instead?

bagder · 2021-09-26T15:23:22Z

@gvanem what selection is that? Is that even something we control?

gvanem · 2021-09-26T16:07:47Z

@bagder In man cmake-env-variables, there is a mention of CMAKE_RC_COMPILER. Could perhaps override the built-in RC for clang?

bagder · 2021-09-26T21:00:02Z

It seems that in order to use that variable someone would have to patch lib/CMakeLists.txt to compile libcurl.rc separately from the other sources with that compiler. I think we can go with the ASCII version until someone finds the time and inspiration to do that change...

vszakats · 2021-09-26T21:33:08Z

rc belongs to MSVC, so it's not available in every LLVM build-scenario. Also the MSVC's rc is also sensitive to codepage issues. So, this may create different problems.

bagder added build Windows labels Sep 23, 2021

bagder added a commit that referenced this issue Sep 23, 2021

libcurl.rc: include curl/curlver.h "correctly"

758eb18

Reported-by: Vitaly Varyvdin Fixes #7765

bagder mentioned this issue Sep 23, 2021

libcurl.rc: include curl/curlver.h "correctly" #7766

Closed

VitalyVaryvdin changed the title ~~Compiling with Clang on Windows fails at libcurlc.rc~~ Compiling with Clang on Windows fails at libcurl.rc Sep 23, 2021

bagder added a commit that referenced this issue Sep 24, 2021

libcurl.rc: switch out the copyright symbol for plain ASCII

486b0e5

Reported-by: Vitaly Varyvdin Assisted-by: Viktor Szakats Fixes #7765

bagder mentioned this issue Sep 24, 2021

libcurl.rc: switch out the copyright symbol for plain ASCII #7776

Closed

bagder closed this in 1ca62bb Sep 26, 2021

curl / curl Public

Compiling with Clang on Windows fails at libcurl.rc #7765

Compiling with Clang on Windows fails at libcurl.rc #7765

VitalyVaryvdin commented Sep 23, 2021 •

edited

bagder commented Sep 23, 2021

VitalyVaryvdin commented Sep 23, 2021 •

edited

bagder commented Sep 23, 2021

VitalyVaryvdin commented Sep 23, 2021 •

edited

vszakats commented Sep 23, 2021 •

edited

VitalyVaryvdin commented Sep 23, 2021 •

edited

vszakats commented Sep 24, 2021

bagder commented Sep 24, 2021

VitalyVaryvdin commented Sep 24, 2021 •

edited

dfandrich commented Sep 25, 2021

vszakats commented Sep 25, 2021

VitalyVaryvdin commented Sep 25, 2021 •

edited

bagder commented Sep 25, 2021

gvanem commented Sep 25, 2021

bagder commented Sep 26, 2021

gvanem commented Sep 26, 2021

bagder commented Sep 26, 2021

vszakats commented Sep 26, 2021 •

edited

curl / curl Public

Compiling with Clang on Windows fails at libcurl.rc #7765

Compiling with Clang on Windows fails at libcurl.rc #7765

Comments

VitalyVaryvdin commented Sep 23, 2021 • edited

I did this

I expected the following

curl/libcurl version

operating system

bagder commented Sep 23, 2021

VitalyVaryvdin commented Sep 23, 2021 • edited

bagder commented Sep 23, 2021

VitalyVaryvdin commented Sep 23, 2021 • edited

vszakats commented Sep 23, 2021 • edited

VitalyVaryvdin commented Sep 23, 2021 • edited

vszakats commented Sep 24, 2021

bagder commented Sep 24, 2021

VitalyVaryvdin commented Sep 24, 2021 • edited

dfandrich commented Sep 25, 2021

vszakats commented Sep 25, 2021

VitalyVaryvdin commented Sep 25, 2021 • edited

bagder commented Sep 25, 2021

gvanem commented Sep 25, 2021

bagder commented Sep 26, 2021

gvanem commented Sep 26, 2021

bagder commented Sep 26, 2021

vszakats commented Sep 26, 2021 • edited

VitalyVaryvdin commented Sep 23, 2021 •

edited

VitalyVaryvdin commented Sep 23, 2021 •

edited

VitalyVaryvdin commented Sep 23, 2021 •

edited

vszakats commented Sep 23, 2021 •

edited

VitalyVaryvdin commented Sep 23, 2021 •

edited

VitalyVaryvdin commented Sep 24, 2021 •

edited

VitalyVaryvdin commented Sep 25, 2021 •

edited

vszakats commented Sep 26, 2021 •

edited