IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Hopefully work around the classic problem with double-checked locking:
Another thread could read xmlParserInitialized == 1 but doesn't see
other initialization results yet due to compiler or hardware reordering.
While unlikely, this seems theoretically possible.
The solution is to add a memory barrier after initializing the data but
before setting xmlParserInitialized. It might be enough to use a second
initialization flag which is only used inside the locked section and
update xmlParserInitialized after unlocking. But I haven't seen this
approach in many articles discussing this issue, so it's possibly
flawed as well.
Also use thread-local storage to store globals on POSIX platforms.
Most importantly, this makes sure that global variable access can't fail
when allocating the global state struct.
If DllMain is used, rely on it working as expected. The old code seemed
to attempt to free global state of other threads if, for some reason,
the DllMain mechanism didn't work.
In a static build, register a destructor with
RegisterWaitForSingleObject.
Make public functions xmlGetGlobalState and xmlInitializeGlobalState
no-ops.
Move initialization and registration of global state objects to
xmlInitGlobalState. Lookup global state with xmlGetThreadLocalStorage
which can be inlined nicely.
Also cleanup global state when using TLS. xmlLastError must be reset.
I recently fixed this for Autotools but said that fixing this for CMake
was not feasible due to it using `find_package` rather than
`pkg_check_modules`. I then thought about it and couldn't find any
reason why CMake couldn't try `pkg_check_modules` first and then fall
back to `find_package`, as that's basically what Autotools does.
I had wanted to use the linker flags generated by CMake when it does
fall back to `find_package`, but it only returns direct paths to the
libraries, as opposed to `-l` flags. Baking these library paths into the
pkg-config and xml2-config files would break static linking and
cross-compiling, so I've stuck with the `-l` flags we already have.
There is no need to set `CMAKE_REQUIRED_LIBRARIES` because we already
add the dependencies to the library target.
Having slept on it, I've realised that baking the dependency CFLAGS into
the pkg-config file is pointless when it is only used to link against
them. It may even cause problems.
Update hash function from classic Jenkins OAAT (dict.c) and a variant of
DJB2 (hash.c) to "GoodOAAT" taken from the SMHasher repo. This hash
function passes all SMHasher tests.
pkg-config supports `Requires.private` and `Libs.private` fields for
static linking. However, if you're building a dynamic binary, then
pkg-config will use the non-private fields, even if just the static
libxml2 is available. This will result in libxml2 being underlinked,
causing the build to fail. The solution is to fold the private fields
into the non-private fields when the shared libxml2 is not being built.
This works for Autotools and CMake. Meson also knows how to handle this
when it automatically generates pkg-config files.
The -I and -L flags you use to build should not necessarily be the same
ones you bake into installed files. If you are building with
dependencies located under a SYSROOT then the installed files should
have no knowledge of that SYSROOT. For example, if the build requires
`-L/path/to/sysroot/usr/lib/foo` then only `-L/usr/lib/foo` should be
baked into the installed files.
pkg-config is SYSROOT-aware, so this issue can be sidestepped by using
the `Requires` field rather than the `Libs` and `Cflags` fields. This is
easily resolved if you rely solely on pkg-config, but this project falls
back to standard Autoconf checks, so a little more effort is required.
Unfortunately, this issue cannot feasibly be resolved for CMake.
`find_package` is used rather than `pkg_check_modules`, so we cannot
tell whether a pkg-config file for each dependency is present or not,
even if `find_package` uses pkg-config behind the scenes. The CMake
build does not record any dependency -I or -L flags into the pkg-config
file anyway. This is a problem in itself, although these dependencies
are most likely installed to standard locations.
Meson is very much better at handling this, as it generates the
pkg-config file automatically using the correct logic.
Introduce load factor as main trigger and increase MAX_HASH_LEN. This
should make growth behavior more predictable.
Raise size limit to INT_MAX. This avoids quadratic behavior with larger
tables.
When parsing with HTML_PARSE_NOIMPLIED, the result document can contain
multiple top-level elements. Rework xmlSAX2StartElement to simply add
the element as a child of ctxt->node or ctxt->myDoc.
Don't invoke xmlAddSibling for non-element parents. The context node
should always be an element node.
Fixes#584.
When legacy support is requested, always enable stubs for FTP and
XPointer location modules which were removed from the standard
configuration. Going forward, the --with-legacy configuration option
should be used to provide maximum ABI compatibility.
Fixes#433.
Add the directory containing libxml2.dll with os.add_dll_directory to
make tests work on MinGW.
This has changed in Python 3.8 but for some reason, the issue only
turned up with Python 3.11 on MinGW. Contrary to documentation, copying
libxml2.dll into the directory containing the .pyd file doesn't work.
