Op 30 dec. 2012 22:31 schreef "Przemysław Pawełczyk" <firstname.lastname@example.org> het volgende:
> On Sun, Dec 30, 2012 at 9:19 PM, Ruben Van Boxem
> <email@example.com> wrote:
> > 2012/12/30 Przemysław Pawełczyk <firstname.lastname@example.org>
> >> Thank you for your recent builds! Unfortunately there is no recent
> >> (regarding to the used revision) non-dw2 release, so I have to go with
> >> some dw2 one.
> > That is untrue: each dw2 build is just additional to the regular builds. I
> > ensured all the dw2 builds are now in gcc-dw2-<version>-release
> > subdirectories, and the normal (sjlj) are in gcc-<version>-release.
> grep for NtQueryVolumeInformationFile in
> i686-w64-mingw32-gcc-4.6.3-2-release-win32_rubenvb.7z: no
> i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z [old]: no
> i686-w64-mingw32-gcc-4.8-unstable-win32_rubenvb.7z: yes
> i686-w64-mingw32-gcc-dw2-4.6.3-2-release-win32_rubenvb.7z: no
> i686-w64-mingw32-gcc-dw2-4.7-1-stdthread-win32_rubenvb.7z: yes
> There is no recent gcc-4.7.2 sjlj (only version from September).
> 4.6.3 (both sjlj and dw2) doesn't have
> http://sourceforge.net/apps/trac/mingw-w64/changeset/5429 in it, so I
> labelled it as "not recent regarding to the used version". And that
> exhausts non-dw2 possibilities.
> >> E.g. i686-w64-mingw32-gcc-dw2-4.7-1-stdthread-win32_rubenvb.7z has
> >> updates I was waiting for, like additions to winternl.h, so I can
> >> finally use NtQueryVolumeInformationFile out-of-the-box. So I thought,
> >> but well, actually that's not really true or I am doing something
> >> wrong.
> >> CU (with #include <winternl.h>) compiles fine, but ld spits "undefined
> >> reference to 'NtQueryVolumeInformationFile@20'", even when I link
> >> ntdll or ntoskrnl (their .a have this function, but preceded with
> >> underscore). Is there any chance you know what's wrong here?
> I did a terrible mistake that I did not catch because of Makefile.
> Sorry for the buzz. The problem was putting -lntdll before .o files.
> > I assume this is some mingw-w64 trunk (v3) addition. For that MinGW-w64
> > version, I recommend the gcc-4.8-unstable build, which is pretty near final
> > release and will be ABI compatible with the final GCC 4.8.0. I CC'ed the
> > mingw-w64 list because they will be able to help you with this problem. (Kai
> > or JonY or Jacek or sezero or whoever, see above). I'm guessing a little
> > test program that shows this issue will be welcome and expedite the
> > resolution of this problem.
> The change I was particularly referring to is:
> So you mean 'unstable' doesn't really mean that unstable? ;)
> I would prefer recent 4.7.2 sjlj, but you've already done a great job
> providing fresh builds (especially considering that automated builds
> no longer work), so I cannot complain at all.
The unstable is more stable than experimental. I got the names from Debian ;-). It's a prerelease, so you might run into trouble. I have no idea how to estimate GCC or MinGW-w64 stability any better :-)
I chose to build the release versions with a released MinGW-w64 version. Experimental and the occasional unstable builds use a more recent MinGW-w64, which is current trunk.
> Przemysław 'Przemoc' Pawełczyk