On FreeBSD, perl isn't in /usr/bin, its in /usr/local/bin or
elsewhere in the path.
Like storage/{maria/unittest/,}ma_test_* , we use /usr/bin/env to
find perl and run it.
On large hard disks (> 2TB), the plugin won't function correctly, always
showing 2 TB of available space due to integer overflow. Upgrade table
fields to bigint to resolve this problem.
DESCRIPTION
===========
PVS-Studio static code analyzer found several suspicious
fragments of code across various files.
i) sizeof() is using the pointer
ii) memcpy() doesn't copy the whole string.
iii) enumeration constant 'wkb_multilinestring' is used as
a variable of a Boolean-type.
iv) 'throw' keyword is missing from std::runtime_error()
FIX
===
i) Use sizeof({actual object/data type})
ii) Use strncpy() and set last char as '\0'
iii) N/A (Issue has already been fixed)
iv) Add 'throw' before the exception.
RB: 21502
Plugin fixed to not lock the LOCK_operations when not active.
Server fixed to lock the LOCK_plugin less - do it once per
thread and then only if a plugin was installed/uninstalled.
innodb_locks_unsafe_for_binlog variabe removed from wsrep_info test configuration and
recommendation to use this variable in README-wsrep was removed as well
Also relates to issue: MDEV-19544
This commit is based on the work of Michal Schorm, rebased on the
earliest MariaDB version.
Th command line used to generate this diff was:
find ./ -type f \
-exec sed -i -e 's/Foundation, Inc., 59 Temple Place, Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \
-exec sed -i -e 's/Foundation, Inc. 59 Temple Place.* Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \
-exec sed -i -e 's/MA.*.....-1307.*USA/MA 02110-1335 USA/g' {} \; \
-exec sed -i -e 's/Foundation, Inc., 59 Temple/Foundation, Inc., 51 Franklin/g' {} \; \
-exec sed -i -e 's/Place, Suite 330, Boston, MA.*02111-1307.*USA/Street, Fifth Floor, Boston, MA 02110-1335 USA/g' {} \; \
-exec sed -i -e 's/MA.*.....-1307/MA 02110-1335/g' {} \;
`zypper install krb5-devel` installs executables outside of $PATH.
It also installs /etc/profile.d/krb5.sh that is sourced by a new
shell to add the new location to the $PATH. But this doesn't affect
the current shell.
Now decent Linux distros remind the user to run `. /etc/profile`
to reload paths in such a case. SUSE doesn't and for a good reason -
it doesn't work there. Because SUSE sets PROFILEREAD=true in the
environment and /etc/profile does not do anything.
By this point, one should not really expect `unset PROFILEREAD` to help,
and it does not - PROFILEREAD is readonly, and cannot be unset.
Apparently SUSE really *really* wants you to re-login between installing
MariaDB build dependencies and actually running the rpmbuild.
Which we cannot do it buildbot. And it would look very user-un-friendly
in the Build Instructions section of the manual.
So, we work around it - by adding SUSE krb5 path to the search list.
THIS IS SUSEEEEEE!!!
special cases:
* change systemd detection to use CHECK_LIBRARY_EXISTS at least once,
to have it detected by build_depends.cmake
* similarly, use find_library for pam
* unixODBC is weird, libodbc.so is in the unixODBC package, not
in the unixODBC-devel, where normally all .so files belong.
Packaging bug? As a workaround, use find_file(sql.h) instead of
find_path(sql.h) to make sure that /usr/include/sql.h (not /usr/include)
is cached by cmake, and later build_depends.cmake will select
unixODBC-devel, as a package owning /usr/include/sql.h file.