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/brows
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
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 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
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
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
2014/1/2 ResQue
> 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 v
2014/1/6 lh_mouse
> 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
