"make_binary_distribution" does not always generate correct names
Originally, we solved deficiencies of the predefined "autoconf" macros
(at least on OS X 10.5, they do not correctly differ between "x86" and
"x86_64") by providing explicit "--platform" arguments.
With this patch, "make_binary_distribution" evaluates CFLAGS, so it
"just works" because CFLAGS contains information about the target CPU.
This patch is accompanied by a change in our build tools that drops the
setting of "--platform" arguments.
scripts/make_binary_distribution.sh:
This is a fix for bug#37808
"make_binary_distribution" does not always generate correct names
Our platform names are the combination of operating system, architecture (CPU),
and a possible suffix (typically "64bit", if a CPU is available in 32 bit too).
We get these values from some predefined "autoconf" macros.
However, these macros are not perfect, especially on OS X 10.5 they do not
differ correctly between x86 (32 bit) and x86_64 (64 bit).
Originally, we solved that by providing an explicit "--platform" argument,
but it is better to get rid of that and ensure the script "just works".
The best indication we have about the CPU is the "CFLAGS" value provided
with "configure" and used in "make": It describes for which CPU the
binaries are generated, not just which one was running the build.
This approach should work even if we implement cross-compilation.
So this patch evaluates CFLAGS and extracts its "-arch XYZ" part.
When touching the file, I also replaced some tab characters by blanks.
occasionally.
mysql_multi can call mysqld_safe. In doing this it's not changing the
current working directory. This may cause confusion in the case where
mysqld_multi is handling instances of servers of different versions
and the current working directory is the installation directory of one
of these servers.
Fixed by enhancing the meaning of basedir in [mysqldN] sections of
mysqld_multi. If specified, mysqld_multi will change the current
working directory to the basedir directory before starting the server
in mysqld_multi ... start ... and then change it back to what it was.
scripts/mysqld_multi.sh:
Bug #36654: optionally preserve, change and restore the cwd when
starting server instances
doesn't find 'logger'
Due to a variable quoting mistake, the $PATH environment
variable isn't parsed correctly when searching for the
existence of the desired executable(s) (logger in this
case).
This patch removes the quotes.
165 changesets with 23 conflicts:
Text conflict in mysql-test/r/lock_multi.result
Text conflict in mysql-test/t/lock_multi.test
Text conflict in mysql-test/t/mysqldump.test
Text conflict in sql/item_strfunc.cc
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/parse_file.cc
Text conflict in sql/slave.cc
Text conflict in sql/sp.cc
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.cc
Text conflict in sql/sql_crypt.cc
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_select.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_view.cc
Text conflict in storage/innobase/handler/ha_innodb.cc
Text conflict in storage/myisam/mi_packrec.c
Text conflict in tests/mysql_client_test.c
Updates to Innobase, taken from main 5.1:
bzr: ERROR: Some change isn't sane:
File mysql-test/r/innodb-semi-consistent.result is owned by Innobase and should not be updated.
File mysql-test/t/innodb-semi-consistent.test is owned by Innobase and should not be updated.
File storage/innobase/handler/ha_innodb.cc is owned by Innobase and should not be updated.
File storage/innobase/ibuf/ibuf0ibuf.c is owned by Innobase and should not be updated.
File storage/innobase/include/row0mysql.h is owned by Innobase and should not be updated.
File storage/innobase/include/srv0srv.h is owned by Innobase and should not be updated.
File storage/innobase/include/trx0trx.h is owned by Innobase and should not be updated.
File storage/innobase/include/trx0trx.ic is owned by Innobase and should not be updated.
File storage/innobase/lock/lock0lock.c is owned by Innobase and should not be updated.
File storage/innobase/page/page0cur.c is owned by Innobase and should not be updated.
File storage/innobase/row/row0mysql.c is owned by Innobase and should not be updated.
File storage/innobase/row/row0sel.c is owned by Innobase and should not be updated.
File storage/innobase/srv/srv0srv.c is owned by Innobase and should not be updated.
File storage/innobase/trx/trx0trx.c is owned by Innobase and should not be updated.
(Set env var 'ALLOW_UPDATE_INNOBASE_OWNED' to override.)
preventing a change that would result in table data loss. (Bug #27149)
Also updated mysql_convert_table_format to use --engine as the documentation
claimed, and use the engine terminology throughout instead of the obsolete
'table type'.
Bug#32136: mysqld_multi --defaults-file not respected while using \
--mysqld=mysqld_safe
Revert change that adds "--no-defaults" to mysqld_multi.
This closes Bug#43508 and re-opens Bug#32136.
(general server part + NDB part)
automatically when creating a binary package,
include only the NDBpart in the package (file) name.
scripts/make_binary_distribution.sh:
The "version" string of a cluster build contains information
about both the general server part and the NDB part.
This is intentional, but it isn't suitable for the package file name.
When packaging a binary build, the script now detects whether
it is dealing with a cluster build or not.
If it is a cluster build, the script now removes the server part
from the version number, leaving the NDB part.
Example: "5.1.31-ndb-6.4.2" -> "6.4.2"
so packages are named like
"mysql-cluster-gpl-6.4.2-linux-i686-glibc23.tar.gz"
The problem is that creating a event could fail if the value of
the variable server_id didn't fit in the originator column of
the event system table. The cause is two-fold: it was possible
to set server_id to a value outside the documented range (from
0 to 2^32-1) and the originator column of the event table didn't
have enough room for values in this range.
The log tables (general_log and slow_log) also don't have a proper
column type to store the server_id and having a large server_id
value could prevent queries from being logged.
The solution is to ensure that all system tables that store the
server_id value have a proper column type (int unsigned) and that
the variable can't be set to a value that is not within the range.
mysql-test/r/events_bugs.result:
Add test case result for Bug#36540
mysql-test/r/log_tables.result:
Update column type.
mysql-test/r/system_mysql_db.result:
Update column type.
mysql-test/r/variables.result:
Add test case result for server_id value range.
mysql-test/suite/sys_vars/r/server_id_basic_64.result:
Update test case results.
mysql-test/t/events_bugs.test:
Add test case for Bug#36540
mysql-test/t/log_tables.test:
Fix column type.
mysql-test/t/variables.test:
Add test case for server_id value range.
scripts/mysql_system_tables.sql:
Columns that store the server_id value must be of type INT UNSIGNED,
fix event (originator), general_log and slow_log (server_id) tables
in accordance.
scripts/mysql_system_tables_fix.sql:
Columns that store the server_id value must be of type INT UNSIGNED,
fix event (originator), general_log and slow_log (server_id) tables
in accordance.
sql/mysqld.cc:
Set min and max values for the server_id variable.
Unfortunately we can't easily change server_id variable type
from ulong to uint32 because of the sys_var classes.
Options got normalised to long rather than short options
since we gave primary name and alias in wrong order.
Consequently querying for the option using the short
options (the correct primary name) didn't work, rendering
the options in question inaccessible.
We restore the right order of the universe, or at least
the alii for --debug and --verbose.
scripts/mysqldumpslow.sh:
Normalise --verbose/-v and --debug/-d to short
options, not long options.
--mysqld=mysqld_safe
The server run didn't know the correct section to read in a
configuration file, and would read from "[mysqld]" even though
mysqld_multi had already read the defaults and made them into explicit
parameters.
Worse, the "defaults-file" parameter says that it means "Read only
this configuration file, do not read the standard system-wide and
user-specific files", which should apply not only to mysql-multi, but
to the server also.
So, now if "defaults-file" is given, put "no-defaults" before all the
explicit parameters we read from the defaults-file and feed to the
mysqld or mysqld_safe.
mysql_config did not output -ldl (or equivalent) when needed for --libmysqld-libs,
so its output could be insufficient to build an application using the embedded
server.
LIBDL was already set in configure; it's now propagated all the way into the
relevant mysql_config scripts.
scripts/Makefile.am:
We "manually" replace configure's constants in .sh scripts using sed,
so AC_SUBST() alone is not good enough. Add LIBDL to the substitution
list; we'll be needing it for mysql_config --libmysqld-libs
scripts/mysql_config.pl.in:
Add LIBDL (usually -ldl) to output of mysql_config --libmysqld-libs (perl version)
scripts/mysql_config.sh:
Add LIBDL (usually -ldl) to output of mysql_config --libmysqld-libs (shell version)
