On Sun, Dec 30, 2012 at 9:19 PM, Ruben Van Boxem <[email protected]> wrote: > > 2012/12/30 Przemysław Pawełczyk <[email protected]> [snip] >> >> 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 mingw-*/i686-w64-mingw32/include/winternl.h 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: http://sourceforge.net/apps/trac/mingw-w64/changeset/5429 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. Regards. -- Przemysław 'Przemoc' Pawełczyk http://przemoc.net/ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
