From: dw <lim...@ya...> - 2013-07-20 09:08:11
|
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. 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 |