Opened 15 years ago
Closed 12 years ago
#389 closed enhancement (fixed)
Incompatibility between code compiled with and without DEBUG
Reported by: | Charlie Hull | Owned by: | Charlie Hull |
---|---|---|---|
Priority: | normal | Milestone: | 1.3.1 |
Component: | MSVC makefiles | Version: | 1.0.14 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | Microsoft Windows |
Description (last modified by )
Martin Margo says: I learned std::string class is not binary compatible between my driver project (VC2008 IDE) and Xapian (built using nmake). I have in my compile option '_DEBUG'. Once I changed my configuration manager to 'Release/Win32' and transferred proper header and include lib dirs, my program runs successfully.
Olly comments:
There are similar issues with GCC and _GLIBCXX_DEBUG which we handle by generating a check in "include/xapian/version.h" that the setting of _GLIBCXX_DEBUG is the same as it was when the library was built - e.g.if you build the library without _GLIBCXX_DEBUG, version.h contains:
#ifdef _GLIBCXX_DEBUG #error You are compiling with _GLIBCXX_DEBUG defined, but the library #error was not compiled with this flag. The settings must match or your #error program will not work correctly. #endif
It would be nice to have a similar check for _DEBUG under MSVC.
Change History (3)
comment:1 by , 15 years ago
Component: | Examples → MSVC makefiles |
---|---|
Owner: | changed from | to
Version: | → 1.0.14 |
comment:2 by , 14 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 1.2.x |
No API or ABI issues (in fact this is catching an incompatible ABI issue) so suitable for 1.2.x.
comment:3 by , 12 years ago
Milestone: | 1.2.x → 1.3.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
In r16899 I've added code to the include/xapian/version_h.cc template so that we get a check for _DEBUG if building with MSVC. However, this only gets used if you use configure with MSVC, which isn't how Charlie builds. I'm not sure if configure with MSVC currently works or not - installing MSYS on windows is one approach. The other is to install MSVC in wine and run configure under Linux, treating MSVC as a cross-compiler. But AFAIK, neither has been tried recently.
With GCC, version.h is generated unchanged (except a (C) date change). Faking what MSVC defines with GCC's preprocessor produces a suitable version.h for MSVC, but I don't know exactly what MSVC outputs in preprocess-only mode, so this might still need tweaks.
I'm marked this as "fixed" for now - we can reopen if it turns out to need more work.
I think at this point this isn't worth backporting. If we actually know it works, it is worth considering.
Setting component sanely, and version while I'm at it.