I have been gathering evidence that the conjecture is true.
Determining the conditions under which a wxWidget library will be binary incompatible with a wxWidget program is clouded because they never get specific about the problem.
I am ignoring the binary incompatibility of windows vrs unix vrs Mac, and the like, because that is binary incompatible for other reasons already.
wxGTK is incompatible if detecting GTK2.0 differs. Code produced differs in handling TAB expansion, as GTK2 will handle TAB itself, but GTK needs a helper function.
wxX11 seems to be incompatible with wxGTK, in that the headers detect and generate different functional defines for some functionality.
Several forums have mentioned that the wxWidgets library should be compiled with the program and then statically linked to it.
This is one way to keep decisions made in the wxWidgets headers compatible.
Finding if two wxWidget libraries are compatible
https://forums.wxwidgets.org/viewtopic.php?t=36780.
Quote:
// NB: This file contains macros for checking binary compatibility of libraries
// in multilib builds, plugins and user components.
// The WX_BUILD_OPTIONS_SIGNATURE macro expands into string that should
// uniquely identify binary compatible builds: i.e. if two builds of the
// library are binary compatible, their signature string should be the
// same; if two builds are binary incompatible, their signatures should
// be different.
//
// Therefore, wxUSE_XXX flags that affect binary compatibility (vtables,
// function signatures) should be accounted for here. So should compilers
// and compiler versions (but note that binary compatible compiler versions
// such as gcc-2.95.2 and gcc-2.95.3 should have same signature!).
|
The OS variations are handled by the top part of that file.
The more troublesome part of that file is near the bottom.
I do not know what options are checked here.
Every option that is checked here would need to be mentioned in the dependency requirements
associated with a downloaded binary.
Quote:
// Use this macro to check build options. Adding it to a file in DLL will
// ensure that the DLL checks build options in same way wxIMPLEMENT_APP() does.
#define WX_CHECK_BUILD_OPTIONS(libName) \
static struct wxBuildOptionsChecker \
{ \
wxBuildOptionsChecker() \
{ \
wxAppConsole::CheckBuildOptions(WX_BUILD_OPTIONS_SIGNATURE, \
libName); \
} \
} gs_buildOptionsCheck;
|
It does not matter if Alien and Ponce have settled on some common settings.
Without knowing exactly what wxWidgets is sensitive to in its environment detection
in the headers, it is hard to even detect compatibility.
You cannot prove compatibility by simplistic testing or one guy successfully compiling.
The problem does not show up at compile-time. You would have to exercise and run-time test
EVERY function in the library to prove that it is binary compatible with a user program.
If the user installs a downloaded library. They can easily forget and later try to compile themselves
a program that uses wxWidgets. I cannot yet determine what settings and options they need to check
to ensure that the program they compiled will be binary compatible with the downloaded library.
Unlike every other library and installed headers, which define static and predictable header structures,
the wxWidgets headers have many #if detections and they are willing to conditionally insert values into enum,
conditionally insert fields into structures, and conditionally define functions and other items.
This is based on a short examination of the headers.
A quick count shows 714 uses of #if in the 700+ wxWidget header files, and I have probably looked at 10 to 20 #if in 6 header files so far.
