Fixes MSI installer.
Do not install hashicorp-key-management, as also we would need to install
dependencies, in this case libcurl. For that, MDEV-33474 needs to be fixed
first.
- When `libcurl` is installed in path out of default path, like on
Windows, `include_directories` failed to find `curl/curl.h`.
- Fix `cmake` by using modern syntax with imported target and
`find_package`
- Fix warnings treated as the errors
- Remove `HASHICORP_HAVE_EXCEPTIONS` macro and related code
- Add package to `Server` component in Windows
- Tested with `$ ./mysql-test/mtr --suite=vault`
- Closes PR #3068
- Reviewer: <wlad@mariadb.com>
<julius.goryavsky@mariadb.com>
With this patch, 4-component MSI version can be used, e.g by setting
TINY_VERSION variable in CMake, or by adding a string, e.g
MYSQL_VERSION_EXTRA=-2
which sets TINY_VERSION to 2, and also changes the package name.
The 4-component MSI versions do not support MSI major upgrades, only minor
ones, i.e do not reinstall components, just update existing ones based
on versioning rules.
To support these rules, add DefaultVersion for the files that won't
otherwise be versioned - headers, static and import libraries,
pdbs, text - xml, python and perl scripts Also silence WiX warning
that MSI won't store hashes for those files anymore.
The MDEV-29693 conflict resolution is from Monty, as well as is
a bug fix where ANALYZE TABLE wrongly built histograms for
single-column PRIMARY KEY.
Also includes a fix for safe_malloc error reporting.
Other things:
- Copied main.log_slow from 10.4 to avoid mtr issue
Disabled test:
- spider/bugfix.mdev_27239 because we started to get
+Error 1429 Unable to connect to foreign data source: localhost
-Error 1158 Got an error reading communication packets
- main.delayed
- Bug#54332 Deadlock with two connections doing LOCK TABLE+INSERT DELAYED
This part is disabled for now as it fails randomly with different
warnings/errors (no corruption).
Refactor CPackWixConfig.cmake so that it complains about unknown CPack
components.
This would prevent missing components,or discrepancy between MSI and ZIP
content, whenever new components are added or renamed.
Also, remove some old stuff, and use macros add_component_group() and
add_component() to reduce the verbosity.
There is a list of plugins in the WiX configuration file for HeidiSQL,
and the installer only installs DLLs from that list although the HeidiSQL
portable archive may include other plugins.
This commit adds client_ed25519.dll to this list and also rearranges
the list alphabetically, so it is easier to verify its contents
If installation directory is not empty, MSI would shows a popup informing
user about it. The error message is stored as MSI property
INSTALLDIRERROR.
Fixed the bug that the error was not cleared, when the user changes
directory in installer UI.
The error message "InnoDB: innodb_page_size=65536 requires innodb_buffer_pool_size >= 20MiB current 10MiB" is the relevant one.
The root cause:
mysql_install_db bootstraps with --innodb-buffer-pool-size=10M.
Small bufferpool is here by design - bootstrap should succeed,
even if there is not much RAM available, bootstrap does not need that much
memory.
For pagesize 64K specifically, Innodb thinks it needs a larger bufferpool,
and thus it lets the bootstrap process die (although the expected behavior
in this case would be to adjust value, give warning and continue)
The workaround:
- pass --innodb-buffer-pool-size=20M, which is suitable for all page sizes.
- check the same limit in MSI custom action.
Also, the patch adds mtr test for 64K page size.
This happens for example if one installs into home directory of a user
C:\Users\<username>\mariadb
The reason is that the service user "NT SERVICE\<service_name>" does
not have read and execute permissions for service executable mysqld.exe
in this directory.
Moreover, it would not have read permissions for server.dll loaded by the
exe, or to plugin directory, where plugins may reside.
The fix is to give service users read and execute permissions to bin, share, and
lib\plugin subdirectories.
The permission setting is doneby mysql_install_db.exe, but also in MSI.
It is important to do that in MSI, as we want permissions to survive
the MSI upgrade.
Two Problems
1. Upgrade wizard failed to retrieve path to service executable,
if it contained non-ASCII.
Fixed by setlocale(LC_ALL, "en_US.UTF8"), which was missing in upgrade wizard
2.mysql_upgrade_service only updated (converted to UTF8) the server's sections
leaving client's as-is
Corrected typo.
3. Fixed assertion in my_getopt, turns out to be too strict.
CreateServiceA, OpenServiceA, and couple of other functions do not work
correctly with non-ASCII character, in the special case where application
has defined activeCodePage=UTF8.
Workaround by redefining affected ANSI functions to own wrapper, which
works by converting narrow(ANSI) to wide, then calling wide function.
Deprecate original ANSI service functions, via declspec, so that we can catch
their use.
