Re: [Mingw-w64-public] Encoding problem with __FILE__ macro
2014/1/6 lh_mouse lh_mo...@126.com Hi guys, I have noticed that in mingw-gcc, the __FILE__ macro expands using the system's code page encoding (e.g. code page 936 on Simplified Chinese Windows systems). I will describe how it causes problems: When a mbcs literal is used in the source file, GCC does not check whether it is legal or not - it simply performs a bytewise copy, just opposite to MSVC, which converts UTF8 string literals to code page string literals. So the following code will work in both mingw-gcc and MSVC, when saved in ANSI text format: std::puts(喵); // \xDF\xF7 in CP936 But the following code will NOT work in GCC: std::fputws(L喵, stdout); // L\xDF\xF7 in CP936 GCC gives this error: error: converting to execution character set: Illegal byte sequence I believe this should be due to the encoding. When GCC finds a wide string literal, it tries to re-encode the string literal from the file into wide string format. In this progress GCC rejects any mbcs encoding but UTF8. Converting the source file encoding to UTF8 would solve this problem but will cause another one: most stdio functions still expects code page strings and will produce gibberish with UTF8 strings. The final sollution: avoid narrow string literals in source files, use wide string literals only. There is still a problem left: some ISO C macros such as __FILE__ still use code page encoding - the following code will produce compile errors if the file's name contains non-ASCII characters: #define TO_WCS2(x) L##x #define TO_WCS(x) TO_WCS2(x) std::fputws(TO_WCS(__FILE__), stdout); Personally I am considering this is a bug because GCC does not actually recognizes code page strings. What do you think about this? If GCC was properly built with iconv support, you can use the option -finput-charset to set your file's encoding so that it is properly read by the compiler. I'm not quite sure how the __FILE__ macro will be affected. In general, it is always better to write code in plain English, as to avoid these issues ;-) See the manual for more information: http://gcc.gnu.org/onlinedocs/cpp/Invocation.html Cheers, Ruben Best regards, 2014-01-06 lh_mouse -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] what is x86_64-w64-mingw32 folder?
2014/1/2 ResQue resque1...@gmail.com Question 1: I downloaded MinGW-W64 today: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-win32/seh/x86_64-4.8.2-release-win32-seh-rt_v3-rev1.7z/download and noticed in the 64bit precompiled version there is a folder called x86_64-w64-mingw32 it seems to contain a couple of files that are already inside the bin folder. What is the purpose of these files? In what scenario should i be using them over the files with the same name inside of the bin folder? These files are internal executables used by binutils and gcc. You should never call these directly. Ignore them. Question 2: Inside the bin folder there are a collection of files named x86_64-w64-mingw32-c++.exe x86_64-w64-mingw32-g++.exe x86_64-w64-mingw32-gcc-4.8.2.exe x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-gcc-nm.exe x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-gcc.exe x86_64-w64-mingw32-gfortran.exe All of these files have a counter part in the same directory, with the x86_64-w64-mingw32- removed. What is the purpose of these files? In what scenario should i be using them? These prefixed versions are provided to satisfy autotools configure scripts and facilitate cross-compiling from e.g. Linux. In the native Windows toolchain case (as you are describing) they make little sense, but it's what the GCC build system creates. Just call the non-prefixed versions, as they are the exact same as their prefixed counterparts. Cheers, Ruben ResQue -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Encoding problem with __FILE__ macro
The problem happens with the encoding of the source file's path, not the file's contents. Anyway I agree with you that it is a good habit to code in plain English. But it is inevitable to involve the file's path in specific situations e.g. when you use the assert() macro. 2014-01-11 lh_mouse -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] what is x86_64-w64-mingw32 folder?
On 1/11/2014 22:24, Ruben Van Boxem wrote: Question 2: Inside the bin folder there are a collection of files named x86_64-w64-mingw32-c++.exe x86_64-w64-mingw32-g++.exe x86_64-w64-mingw32-gcc-4.8.2.exe x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-gcc-nm.exe x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-gcc.exe x86_64-w64-mingw32-gfortran.exe All of these files have a counter part in the same directory, with the x86_64-w64-mingw32- removed. What is the purpose of these files? In what scenario should i be using them? These prefixed versions are provided to satisfy autotools configure scripts and facilitate cross-compiling from e.g. Linux. In the native Windows toolchain case (as you are describing) they make little sense, but it's what the GCC build system creates. Just call the non-prefixed versions, as they are the exact same as their prefixed counterparts. You have it backwards. While it is the norm to assume that Windows is downright incapable of doing anything right at all, cross compiling is actually possible there, even without autotools, just call the prefixed version and you are set. No guessing games about what gcc is producing for output. signature.asc Description: OpenPGP digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Encoding problem with __FILE__ macro
Putting source files in anything but ascii folders is asking for trouble. Lots of trouble. Just don't. On Sat, Jan 11, 2014 at 2:38 PM, lh_mouse lh_mo...@126.com wrote: The problem happens with the encoding of the source file's path, not the file's contents. Anyway I agree with you that it is a good habit to code in plain English. But it is inevitable to involve the file's path in specific situations e.g. when you use the assert() macro. 2014-01-11 lh_mouse -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for January 11 2014
This is a report for the 20140111 mass rebuild of all Fedora MinGW
packages against Fedora Rawhide and a list of all the changes which
have been applied since the previous mass rebuild.
During this mass rebuild the following toolchain was used:
* mingw-w64 3.1.0
* binutils 2.23.52.0.1
* gcc 4.8.2
Statistics about current mass rebuild:
--
Timestamp of mass rebuild: 20140111
Total packages: 182
Number of failed packages: 1
Number of succeeded packages: 181
Number of added packages since previous mass rebuild: 0
Time needed to perform mass rebuild: 42 hours, 4 minutes, 25 seconds
Statistics about previous mass rebuild:
---
Timestamp of previous mass rebuild: 20131204
Total packages: 182
Number of failed packages: 0
Number of succeeded packages: 182
===
The following packages FAILED to rebuild:
mingw-libgsf-1.14.28-1
** Package failed to build while it succeeded during the previous mass
rebuild **
Package owner: greghellings
Time to build: 3 minutes, 16 seconds
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140111/mingw-libgsf-1.14.28-1
===
The following packages were updated since the previous rebuild:
mingw-atk-2.11.3-1.fc19
* Thu Dec 05 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.11.3-1
- Update to 2.11.3
- Export the symbol atk_object_get_object_locale (required by webkitgtk)
mingw-crt-3.1.0-1.fc19
---
* Thu Jan 09 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.0-1
- Update to 3.1.0
mingw-gcc-4.8.2-2.fc19
---
* Fri Jan 10 2014 Erik van Pienbroek epien...@fedoraproject.org - 4.8.2-2
- Dropped xmmintrin patch as the issue is resolved in mingw-w64 3.1.0
mingw-glib2-2.39.2-1.fc19
--
* Tue Dec 17 2013 Erik van Pienbroek epien...@fedoraproject.org - 2.39.2-1
- Update to 2.39.2
mingw-gmp-5.1.3-1.fc19
---
* Tue Jan 07 2014 Michael Cronenworth m...@cchtml.com - 5.1.3-1
- New upstream release.
mingw-gstreamer1-1.2.1-1.fc19
--
* Wed Dec 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.2.1-1
- Update to 1.2.1
mingw-gstreamer1-plugins-base-1.2.1-1.fc19
---
* Wed Dec 04 2013 Erik van Pienbroek epien...@fedoraproject.org - 1.2.1-1
- Update to 1.2.1
mingw-headers-3.1.0-1.fc19
---
* Thu Jan 09 2014 Erik van Pienbroek epien...@fedoraproject.org - 3.1.0-1
- Update to 3.1.0
mingw-libzip-0.11.2-1.fc19
---
* Thu Dec 19 2013 Sandro Mani manisan...@gmail.com - 0.11.2-1
- Update to 0.11.2
mingw-poppler-0.24.5-1.fc19
* Fri Jan 03 2014 Sandro Mani manisan...@gmail.com - 0.24.5-1
- Update to 0.24.5, fixes #1048203
mingw-postgresql-9.3.2-1.fc19
--
* Tue Jan 07 2014 Michael Cronenworth m...@cchtml.com - 9.3.2-1
- New upstream release.
mingw-qt5-qt3d-5.0.0-0.9.git20130923.7433868.fc19
--
* Wed Jan 08 2014 Erik van Pienbroek epien...@fedoraproject.org -
5.0.0-0.9.git20130923.7433868
- Dropped manual rename of import libraries
* Sun Jan 05 2014 Erik van Pienbroek epien...@fedoraproject.org -
5.0.0-0.8.git20130923.7433868
- Update to 20130923 snapshot (rev 7433868)
This is the last Qt 5.2 based revision
mingw-qt5-qtactiveqt-5.2.0-2.fc19
--
* Fri Jan 10 2014 Erik van Pienbroek epien...@fedoraproject.org - 5.2.0-2
- Added license files
* Mon Jan 06 2014 Erik van Pienbroek epien...@fedoraproject.org - 5.2.0-1
- Update to 5.2.0
mingw-qt5-qtbase-5.2.0-3.fc19
--
* Mon Jan 06 2014 Erik van Pienbroek epein...@fedoraproject.org - 5.2.0-3
- Split the cmake patch and moved half of its contents to the 'implib dll'
patch and the other to the 'use external angle' patch as those are more
proper locations
* Sun Jan 05 2014 Yaakov Selkowitz yselkow...@users.sourceforge.net - 5.2.0-2
- Fix qmake to use .dll.a extension for implibs (avoids renaming hacks in
all mingw-qt5-* packages)
- Force usage of system zlib in Qt5Bootstrap
- Install shared libQt5BootstrapDBus for qdbuscpp2xml and qdbusxml2cpp
- Fix QMAKE_LIBS_NETWORK for static linkage
- Closes RHBZ #1048677
* Sun Jan 05 2014 Erik van Pienbroek epien...@fedoraproject.org - 5.2.0-1
- Update to 5.2.0
- Use the generic win32-g++ mkspecs profile instead of win32-g++-cross
and win32-g++-cross-x64 (as is preferred by upstream)
- Add support for qtchooser
- Moved the native tools to /usr/$target/bin/qt5 (qtchooser requires the
tools to be in an unique folder with their original file names)
All symlinks in %{_bindir} are updated to reflect this as well
- Prevent invalid
Re: [Mingw-w64-public] Mass rebuild report for January 11 2014
On 2014-01-11 15:16, Erik van Pienbroek wrote: The following packages FAILED to rebuild: mingw-libgsf-1.14.28-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: greghellings Time to build: 3 minutes, 16 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140111/mingw-libgsf-1.14.28-1 This is GNOME bug 712827[1], fixed upstream in 1.14.29[2]. Yaakov Cygwin Ports [1] https://bugzilla.gnome.org/show_bug.cgi?id=712827 [2] https://git.gnome.org/browse/libgsf/commit/?id=54bc048 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
