待辦事項 #39639

no iconv implementation

啟用日期: 2019-10-06 02:58 最後更新: 2019-10-14 02:38

回報者:
負責人:
類型:
狀態:
關閉
元件:
里程碑:
(無)
優先權:
5 - 中
嚴重程度:
5 - 中
處理結果:
修正
檔案:
3
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

細節

I have been used mingw-gcc for a long time. However, I found the '-finput-charset=' option not always works correctly across versions. For example, with the latest mingw-gcc version 8.2.0-4, runing 'gcc -finput-charset=GB18030 helloworld.c' will throw out error, which says 'no iconv implementation'.

My further investigation shows the iconv support wasn't compile into mingw-gcc 8.2.0-4. The error message 'no iconv implementation' (which is located in gcc's charset.c) will only be compiled into cc1.exe when HAVE_ICONV is false.

I downloaded serveral versions of cc1.exe, from gcc 5 to gcc 8. I found 5.3.0-2 and 6.3.0-1 had iconv compiled in, but 5.3.0-3, 7.3.0-1, 8.2.0-4 had no iconv complied in.

I googled the error message 'no iconv implementation', and I found many similar issues, some even dated back to 2009, but there is no clear solution or explaination. I think there might be a problem in your build script, such as some kind of race condition, which will lead to configuration script not find iconv library.

Ticket History (3/10 Histories)

2019-10-06 02:58 Updated by: zhangboyang
  • New Ticket "no iconv implementation" created
2019-10-11 21:49 Updated by: keith
評語

Reply To zhangboyang

I downloaded serveral versions of cc1.exe, from gcc 5 to gcc 8. I found 5.3.0-2 and 6.3.0-1 had iconv compiled in, but 5.3.0-3, 7.3.0-1, 8.2.0-4 had no iconv complied in.

Strictly, none have it compiled in, but all are supposed to link dynamically to libiconv-2.dll; of course, it is a justifiable claim that, at the very least, the shared object references should be compiled in.

I googled the error message 'no iconv implementation', and I found many similar issues, some even dated back to 2009, but there is no clear solution or explaination.

The explanation lies in this sixteen year old GCC bug report; first reported against GCC-3.4.0, in 2003, it seems to be generic to GCC core, afflicting all versions since, likely affecting all platforms, and remaining unresolved to this day. I was previously unaware of it; thanks for bringing it to my attention.

I think there might be a problem in your build script, such as some kind of race condition, which will lead to configuration script not find iconv library.

Nope. My build scripts are correct, save for the problem that they take GCC documentation at face value, and rely on --with-libiconv-prefix behaving as documented, (which it doesn't); that some of my previous GCC builds did exhibit iconv functionality is no more than a lucky accident.

Now that I'm aware of the GCC bug, I can work around it, but maybe the GCC crew need to be nagged into putting their house in order — sixteen years of doing absolutely nothing about a well defined bug seems kind of ridiculous; they should either fix the bug, or fix the documentation.

2019-10-12 19:17 Updated by: keith
  • 負責人 Update from (無) to keith
評語

I've rebuilt GCC 8.2.0 with the libiconv location added to my build compiler's implicit search path, (via the specs file). I now see:

$ mingw32-ldd gcc/cc1.exe 
gcc/cc1.exe
 +- ADVAPI32.DLL
 +- KERNEL32.dll
 +- msvcrt.dll
 +- msvcrt.dll
 +- USER32.dll
 +- libgmp-10.dll
 |   +- KERNEL32.dll
 |   +- msvcrt.dll
 |   +- msvcrt.dll
 +- libiconv-2.dll
 |   +- kernel32.dll
 |   +- msvcrt.dll
 |   +- msvcrt.dll
 +- libisl-15.dll
 |   +- :
 |   +- :
 |   +- :
(where previously, the libiconv-2.dll reference was missing).

I've uploaded this as a gcc-8.2.0-5-mingw32 package set. Please test this, and confirm that it resolves the issue for you.

2019-10-12 21:50 Updated by: zhangboyang
評語

Thanks for your reply. But I don't know how to install the new package set, is there any documention? The gcc version in latest mingw-get catalog is still 8.2.0-4.

2019-10-13 19:19 Updated by: keith
評語

Reply To zhangboyang

I don't know how to install the new package set, is there any documention?

You could simply download the respective tarballs, and extract them over your existing GCC-8.2.0 installation; they are packed relative to the installation root directory, and no, there is no specific documentation for such a trivial operation. However, it isn't normally recommended to overwrite an installation, which is managed by mingw-get, in this manner, (although it would be safe in this instance, provided you don't install any previously uninstalled component packages by this method); you may prefer to replace your existing local copy of $MINGW_ROOT/var/lib/mingw-get/data/mingw32-gcc4.xml (where $MINGW_ROOT represents the root directory of your installation) with this prepublication snapshot, then use mingw-get to install the upgrade.

The gcc version in latest mingw-get catalog is still 8.2.0-4.

It is, and it will remain so for the time being, because I don't want to publish an untested upgrade. Since your report neglects to provide the obligatory SSCCE, I am delegating the testing activity to you.

2019-10-13 22:38 Updated by: zhangboyang
評語

OK, I can confirm the new gcc worked for me. Thank you for fixing this bug.

2019-10-14 02:38 Updated by: keith
  • 元件 Update from OTHER to GCC
  • 狀態 Update from 開啟 to 關閉
  • 處理結果 Update from to 修正
評語

Reply To zhangboyang

I can confirm the new gcc worked for me.

Thanks. I've published it.

Attachment File List

編輯

Please login to add comment to this ticket » 登入