Op 30 dec. 2012 22:31 schreef "Przemysław Pawełczyk" <[email protected]>
het volgende:
>
> 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.
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.
Cheers,
Ruben
>
>
> 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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
