Open Hawaii-ol opened 1 year ago
That iconv program comes from busybox-w32, and GCC wants to be linked against iconv, not use a program. Because GDB already requires iconv, I could build it a bit earlier in the process and let GCC pick it up as well. I'll see how that goes.
Thank you in advance!
It was almost as simple as I expected: Build libiconv sooner, then tell GCC how to find it. The charset compiler options work as you'd expect in these builds with no complaints about missing iconv. However, it makes w64devkit about 10% larger overall. GCC's build is not thoughtful about static libiconv, and so it links a full copy into each GCC executable even though only one needs it.
I'm definitely sticking to a static libiconv for GDB because I really like that gdb.exe completely standalone. Anyone can pluck it out of the kit and use it by itself without DLL hell. Perhaps it's worth also building a shared libiconv just for GCC. I'll need to think on this. For now these changes live in the libiconv-gcc branch.
I need to do some charset conversion. When I specify
-finput-charset=UTF-8
and-fexec-charset=gbk
gcc fails withcc1.exe: error: no iconv implementation, cannot convert from UTF-8 to gbk
I do findiconv.exe
in bin directory but somehow it doesn't seem to be recognized bycc1.exe
.