ghazan,
his difference exists because for Miranda libmdbx was synced with master, not with stable/0.2. if you insist that master shall not be used, I can easily roll back libmdbx to 0.2
git subtree and git submodule not only allow this, but are designed to do so.
moreover, there are too many differences to correlate them with the libmdbx's changelog - this is the trouble.
Anyway, I'd like you to put the code in perfect condition.
Including, later, resolving all of my comments on libmdbx' API usage (as far as I remember there were ones).
This is important for durability, performance and minimize database file size.also, the code of mdbx_load & mdbx_save utilities cannot be imported directly, because of problems of printing cyrillic error messages from the file system. thus using libmdbx as a subtree isn't possible
Please fill corresponding issue at
https://github.com/leo-yuriev/libmdbx/issues and I will fix it.
also, what is the sense of having libmdbx if we coudn't use it as a shared module? in Windows we aren't afraid of using them
The problem is not libmdbx, but how you collect and use it.
If I am not mistaken, you need support for very old versions of Windows, which had and have problems with Thread-Local-Storage destructors when unloading DLL.
Due this you build libmdbx in the configuration, which can create problems in some scenarios.
However, currently libmdbx inside Miranda is only used by MDBX-driver which is always loaded and unloaded explicitly. Therefore, the embedding libmdbx as a static libraries only in this driver looks safe and rational decision.
dartraiden,
btw, our biggest problem with libmdbx is crashing under Wine
Likely that the problem in Wine, not in libmdbx.
However, if you fill an issue at
https://github.com/leo-yuriev/libmdbx/issues (with backtrace(s), etc) I will try to fix.
For instance - does works or crashes "
mdbx_test.exe basic" in case you build the 'clean' mdbx from the original source code?