2013/7/20 dw <[email protected]>
> So, Erik was kind enough to try re-running some of his builds with the
> latest patches to winbase.h. With a bit of tweaking to the patch, x86 now
> builds. While I haven't checked it in yet, these DLLIMPORT things are
> fixed.
>
> Unfortunately, x64 does not build correctly. If you want to see the raw
> details:
>
> Error log: http://fpaste.org/26679/42789171/raw/
> -E output from one of the failing files:
> http://vanpienbroek.nl/SaslFactory.obj
> The important source file is
> http://svn.boost.org/svn/boost/trunk/boost/detail/interlocked.hpp. It is
> currently using the definitions from line 143.
>
> To save you the time, the problem is that for x64, they are NOT including
> winbase.h (which
> MSDN<http://msdn.microsoft.com/en-us/library/ms683614%28v=VS.85%29.aspx>says
> is where the def exists). They are (as before) using their own def.
> Since they are not using our headers, the intrinsics are not available, and
> the mapping from the PSDK function to the intrinsic (which is what MS does
> for x64) isn't done.
>
> This used to work before my patch because intrincs/ilockinc.c used to
> (incorrectly, in my opinion) have definitions for both the intrinsic
> (_InterlockedIncrement) and the PSDK (InterlockedIncrement). Now it only
> has _InterlockedIncrement. FYI, while MSDN says that this function is in
> kernel32.lib, that is only true for x86.
>
> So, that's what's happening. Now, what do we do about it? A few
> alternatives that occur to me (in no particular order).
>
> Boost could:
> 1) Use winbase.h (via windows.h) like the MSDN docs say they should. In
> fact, I wonder if defining BOOST_USE_WINDOWS_H would work.
> 2) In the #if defined(__MINGW64__) block just above, they could add these
> underscore defines along with #include <intrin.h>.
> 3) They could probably just add the defines for the underscores to the
> __MINGW64__ block. Unlike 1 & 2, this would NOT get them the inlines, but
> would resolve from the library like it did before.
>
> Or, we could:
> 4) Add InterlockedIncrement back to ilockinc.c (likewise for the other
> half dozen or so functions here), probably using alias.
>
> An argument could be made that we have broken backward compatibility and
> it's our responsibility to fix it. On the other hand, one could say they
> are using our library incorrectly (by not including any of our headers),
> and the fact that it worked at all was a fluke and inconsistent with the
> MSDN docs.
>
I vote for this. Boost can always be fixed, and it contains lots of ugly
hacks around various platform obscurities. I think MSVC intrinsics combined
with GCC are a valid obscurity.
Granted, if Boost is to change, you might as well give them the best
performance while we're at it :)
Why not explain it to the Boost mailing list? I'm rather sure they'd be
inclined to accomodate us, if there's no fundamental problems with the
changes.
Ruben
>
> Making things work like they did before (#4) causes the fewest problems
> for boost. 1 & 2 are cleaner fixes that will help boost produce better
> code, and keep our own code cleaner, but might irritate the boost folks
> (and possibly others).
>
> I'm (reluctantly) prepared to add the defs back to the library if that
> seems like the right thing to do. But I could use some guidance about what
> the right thing to do is.
>
> dw
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
