Repository navigation
./configure fails with Unicode build #7229
Description
Activity
EDIT: Better solution exists. Please see here!
Possible workaround, if we don't want to patch the
configurescript, would be using a tiny "shim" library that implements thewmain()function, in order to fix the linker error about missingwmain(orwWinMain) entry point, and that does nothing but invoking the "real"main()function. Libary needs to be added toLIBSenvironment variable when invoking./configure.libwmain.c:extern int main(int argc, char *argv[]); int wmain(void) { char *args[] = { "a.exe", (void*)0 }; return main(1, (char**)args); }Makefile:libwmain.a: libwmain.o $(AR) rcs libwmain.a libwmain.o libwmain.o: libwmain.c $(CC) -march=i386 -Os -o libwmain.o -c libwmain.cTo build curl:
CFLAGS="-munciode -mconsole" LIBS="-lwmain" ./configureNote: In my test, this did not collide with curl's own
wmain()method, but did fix the conftests.Can you use -DUNICODE -D_UNICODE instead
Can you use -DUNICODE -D_UNICODE instead
Sorry, but nope. Or I am missing something? 😕
-
According to my tests,
-municode -mconsolealready implies-DUNICODE -D_UNICODE, so explicitely adding-DUNICODE -D_UNICODEto CFLAGS in addition to-municode -mconsoledoes not change anything for me. -
Setting only
-DUNICODE -D_UNICODEin CFLAGS but not-municode -mconsolecauses MinGW/GCC to still link againstmain()rather thanwmain()– this I have just verified! As a result,./configuredoes succeed without additional hacks, yes. But, in the end, the linking ofcurl.exefails with an undefined reference error – which is expected, because with-D_UNICODEwe are tellingtool_main.cto generatewmain()instead ofmain(), but at the same time MinGW/GCC is expecting amain()function due to the lack of-municode -mconsoleswitches. Hence, setting-DUNICODE -D_UNICODEalone is not sufficient 😞
This was tested with latest MinGW/GCC:
gcc version 10.3.0 (Rev2, Built by MSYS2 project)Best regards.
Reacted by Qmily-
So we'd have to apply -municode only for the curl tool?
Yes, I think so. But it seems that
CURL_LDFLAG_EXTRAS_EXEdoes nothing for me. I did a full-text search on both,configureand the resultingMakefile, but could not find the identifierCURL_LDFLAG_EXTRAS_EXEat all. Does it even exist in "vanilla" curl?However, what does work for me is:
CFLAGS="-DUNICODE -D_UNICODE" ./configure make curl_LDFLAGS="-all-static -municode -mconsole"So that probably is the way to go. Still, figuring this out was wearisome. Maybe add a
./configureoption for Unicode build?Thank you and best regards.
(BTW: What is the difference between
CURL_CFLAG_EXTRASandCFLAGSvariables?)Maybe add a
./configureoption for Unicode build?Seems like a good idea.
(BTW: What is the difference between
CURL_CFLAG_EXTRASandCFLAGSvariables?)I think it was added to pass cflags without overriding the default CFLAGS. It's not documented and I may be wrong...
CURL_LDFLAG_EXTRAS_EXEisMakefile.m32specific, so it indeed doesn't do anything with./configurebuilds.CURL_CFLAG_EXTRASis also something used only inMakefile.m32. This build method doesn't support aCFLAGSfrom the environment, so this "extra" envvar is used to inject extra C flags into it.This issue seems to have stalled. Is there anything we can/should do about this report? Any proposed next steps?
I think it'd be best to complete Unicode support in libcurl and then fix the different build systems to enable it correctly. Though these two can be done in any order or in parallel. @jay had a nice patch for the former, though I continue to think that fall-back methods are bad and should not be used in libcurl. (Yes, OpenSSL uses one such method, but OpenSSL also keeps at least one Windows vulnerability open since years without intention to fix it (along some other past woes on Windows), so I think it should not be regarded as the yardstick for Windows-development specifically.)
I think it'd be best to complete Unicode support in libcurl and then fix the different build systems to enable it correctly. Though these two can be done in any order or in parallel. @jay had a nice patch for the former, though I continue to think that fall-back methods are bad and should not be used in libcurl.
👍 ⚡
5 remaining items
- added 2 commits that reference this issue
on Jul 19, 2023 - added 2 commits that reference this issue
on Aug 9, 2024 - added a commit that references this issue
on Aug 14, 2024 Just tried the new
--enable-windows-unicodeconfigure option in 8.10.0.Still same old problem: Configure script doesn't find "main" function, because, in Windows, when Unicode is enabled, the main function must be
wmain()rathermain(), but it's apparently hard-coded tomain()in your configure script:C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexewin.c:67:(.text+0xc1): undefined reference to `wWinMain@16' collect2.exe: error: ld returned 1 exit status configure:5018: $? = 1 configure:5058: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "curl" | #define PACKAGE_TARNAME "curl" | #define PACKAGE_VERSION "-" | #define PACKAGE_STRING "curl -" | #define PACKAGE_BUGREPORT "a suitable curl mailing list: https://curl.se/mail/" | #define PACKAGE_URL "" | /* end confdefs.h. */ | | int main (void) | { | | ; | return 0; | } configure:5063: error: in `/d/_Sandbox/curl/build/x86/curl': configure:5065: error: C compiler cannot create executables See `config.log' for more detailsHence, the following hack still is required:
sed -i -E 's/\bmain[[:space:]]*\(([^\(\)]*)\)/wmain(\1)/g' configurecurl has a CI job that builds and tests fine without this hack:
https://github.com/curl/curl/actions/runs/10835445722/job/30067013990#step:8:936I've found that
wmainis only necessary when linking with-municode. The merged implementation does that only for the curl tool, so everything else continues to build withmain, as before.The hack also doesn't address building curl tests, which all use
main.I've found that wmain is only necessary when linking with
-municodeYeah, that's right. But
-municodemust be added toLDFLAGSin order to produce a working Unicode binary.If
-municodeis not added toLDFLAGS, then the normalmain()function will be used, which might avoid the linking issues with the Configure script, but it also means that the command-line will be mangled (i.e. any non-US-ASCII character will be replaced by a?character!) even before it arrives in "main" function. So, even if all the rest is compiled as Unicode, we have a problem!To actually get the untainted command-line into the "main" function, as Unicode (UTF-16), we have to use a
wmain()function, which requires-municodeto be added toLDFLAGS(with MinGW-w64) – which then breaks the Configure script, since all the C code generated/executed by the Configure script apparently expects amain()function in a "hardcoded" way.Therefore, I think that
--enable-windows-unicodeshall be adding-municodeto theLDFLAGS. But then we also need something in the Configure script that conditionally (i.e. when--enable-windows-unicodeis used and thus-municodeis in effect) generateswmain()functions instead ofmain(). Until that is implemented, manually patching Configure is still required...(I posted the result when
-municodeis used, but Configure it is not manually patched above. As you can see, it's failing right away. Currently, passing the new option--enable-windows-unicodeapparently does nothing to fix this issue)
I have a workaround that works for me. But I think a proper solution could be great for other users that face the same issue.
I've found that wmain is only necessary when linking with
-municodeYeah, that's right. But
-municodemust be added toLDFLAGSin order to produce a working Unicode binary.As mentioned in the previous post,
-municodeis added for the curl tool automatically. The curl tool does usewmain():
Lines 54 to 56 in 8ca6030
Lines 218 to 228 in 8ca6030
[ Generally speaking:
-municodecontrols the app startup code, and Unicode app code can live without it if it doesn't want to get a wide argv via main. There are other means to retrieve the command-line in Unicode too. So no,-municodeisn't required for a Unicode app. The curl tool uses it, the feature tests and regression tests don't. ](I posted the result when
-municodeis used, but Configure it is not manually patched above. As you can see, it's failing right away. Currently, passing the new option--enable-windows-unicodeapparently does nothing to fix this issue)You seem to be passing
LDFLAGS=-municodeto the build and that is what breaks it for you. The solution is to drop this setting and use--enable-windows-unicodeonly.Have you tried such build?
Reacted by Marcel Raad and LoRd_MuldeRAh, I see now. You mean we can leave out
-municodefrom theLDFLAGSfor the./configureinvocation now (something that was absolutely required in the past!) and then--enable-windows-unicodewill sneak it in again, but only for linking the final cURL executable? Will have to give this a try, and see if there are any undesired side effects with any of the dependencies...Reacted by Marcel RaadAh, I see now. You mean we can leave out
-municodefrom theLDFLAGSfor the./configureinvocation now (something that was absolutely required in the past!) and then--enable-windows-unicodewill sneak it in again, but only for linking the final cURL executable? Will have to give this a try, and see if there are any undesired side effects with any of the dependencies...Indeed, seems to work 🥳
Reacted by Marcel Raad
I did this
I am trying to build curl with Unicode support on Windows (using MinGW/MSYS2).
In order to enable Unicode, I added options
-munciodeand-mconsoleto the CFLAGS explicitely, because apparently./configuredoesn't have a dedicated--enable-unicodeswitch. Or did I miss something?Unforntunately, this caused
./configureto fail with "No working C compiler" error. My analysis of theconfig.logshowed that./configureuses a lot of "test" programs that havemain()hardcoded, but should be usingwmain()when Unicode is used! In the actual curl source codes we already do have the required#ifdefs to use eithermain()orwmain()as needed. Only the./configurehas problem! My workaround was to replace all occurences of "main" in./configurewith "wmain", using a simplesedcommand. This does work. After patchingconfigure, the Unicode version of curl compiled without any problem!But this workaround is rather cumbersome and other people may run into the same issue. So I think it would be much preferable to have an
--enable-unicodeswitch that not only addes-munciodeand-mconsoleto the CFLAGS automatically but also uses the "correct" main function in the "test" programs. At least make./configurework with-munciode -mconsoleoptions.I expected the following
CFLAGS="-municode -mconsole" ./configure && makeshould "just work" without the need to patchconfigure.Even better,
./configure --enable-unicode && makeshould be available.curl/libcurl version
7.77.0
operating system
Windows 10, using latest MinGW/MSYS2 compiler + build environment