- developers - lists.mariadb.org

[Maria-developers] Rev 22: Cannot set both --rand-init and --rand-seed in file:///Users/hakan/work/monty_program/mariadb-tools/
by Hakan Kuecuekyilmaz 09 Mar '10

09 Mar '10

At file:///Users/hakan/work/monty_program/mariadb-tools/ ------------------------------------------------------------ revno: 22 revision-id: hakan(a)askmonty.org-20100309150622-0cpj0wxp3oxsuhep parent: hakan(a)askmonty.org-20100309142133-07u5qhnsa74is32n committer: Hakan Kuecuekyilmaz <hakan(a)askmonty.org> branch nick: mariadb-tools timestamp: Tue 2010-03-09 16:06:22 +0100 message: Cannot set both --rand-init and --rand-seed === modified file 'sysbench/run-sysbench-myisam.sh' --- a/sysbench/run-sysbench-myisam.sh 2010-03-09 14:21:33 +0000 +++ b/sysbench/run-sysbench-myisam.sh 2010-03-09 15:06:22 +0000 @@ -105,7 +105,6 @@ --mysql-user=root \ --mysql-engine-trx=no \ --myisam-max-rows=50000000 \ - --rand-init=on \ --rand-seed=303" # Timeout in seconds for waiting for mysqld to start. === modified file 'sysbench/run-sysbench.sh' --- a/sysbench/run-sysbench.sh 2010-03-09 14:04:29 +0000 +++ b/sysbench/run-sysbench.sh 2010-03-09 15:06:22 +0000 @@ -111,7 +111,6 @@ --mysql-table-engine=InnoDB \ --mysql-user=root \ --mysql-engine-trx=yes \ - --rand-init=on \ --rand-seed=303" # Timeout in seconds for waiting for mysqld to start.

1 0

[Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2797)
by knielsen＠knielsen-hq.org 09 Mar '10

09 Mar '10

#At lp:maria 2797 knielsen(a)knielsen-hq.org 2010-03-09 [merge] Automerge for buildbot test modified: mysql-test/suite/pbxt/r/partition_error.result mysql-test/suite/pbxt/r/partition_pruning.result mysql-test/suite/pbxt/t/partition_error.test sql/item_subselect.cc sql/item_subselect.h sql/sql_partition.cc sql/table.cc === modified file 'mysql-test/suite/pbxt/r/partition_error.result' --- a/mysql-test/suite/pbxt/r/partition_error.result 2009-04-02 10:03:14 +0000 +++ b/mysql-test/suite/pbxt/r/partition_error.result 2010-03-09 15:03:54 +0000 @@ -107,7 +107,7 @@ primary key(a,b)) partition by hash (rand(a)) partitions 2 (partition x1, partition x2); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ') +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ') partitions 2 (partition x1, partition x2)' at line 6 CREATE TABLE t1 ( @@ -118,7 +118,7 @@ primary key(a,b)) partition by range (rand(a)) partitions 2 (partition x1 values less than (0), partition x2 values less than (2)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ') +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ') partitions 2 (partition x1 values less than (0), partition x2 values less than' at line 6 CREATE TABLE t1 ( @@ -129,7 +129,7 @@ primary key(a,b)) partition by list (rand(a)) partitions 2 (partition x1 values in (1), partition x2 values in (2)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ') +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ') partitions 2 (partition x1 values in (1), partition x2 values in (2))' at line 6 CREATE TABLE t1 ( @@ -244,7 +244,7 @@ c int not null, primary key (a,b)) partition by key (a) subpartition by hash (rand(a+b)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 7 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 7 CREATE TABLE t1 ( a int not null, b int not null, @@ -341,7 +341,7 @@ partition by range (3+4) partitions 2 (partition x1 values less than (4) tablespace ts1, partition x2 values less than (8) tablespace ts2); -ERROR HY000: Constant/Random expression in (sub)partitioning function is not allowed +ERROR HY000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed CREATE TABLE t1 ( a int not null, b int not null, @@ -511,7 +511,7 @@ partition by list (3+4) partitions 2 (partition x1 values in (4) tablespace ts1, partition x2 values in (8) tablespace ts2); -ERROR HY000: Constant/Random expression in (sub)partitioning function is not allowed +ERROR HY000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed CREATE TABLE t1 ( a int not null, b int not null, @@ -603,13 +603,13 @@ partition by range (ascii(v)) ERROR HY000: This partition function is not allowed create table t1 (a int) partition by hash (rand(a)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 2 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 2 create table t1 (a int) partition by hash(CURTIME() + a); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 2 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 2 create table t1 (a int) partition by hash (NOW()+a); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 2 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 2 create table t1 (a int) partition by hash (extract(hour from convert_tz(a, '+00:00', '+00:00'))); ERROR HY000: This partition function is not allowed === modified file 'mysql-test/suite/pbxt/r/partition_pruning.result' --- a/mysql-test/suite/pbxt/r/partition_pruning.result 2009-08-17 15:57:58 +0000 +++ b/mysql-test/suite/pbxt/r/partition_pruning.result 2010-03-09 15:03:54 +0000 @@ -527,7 +527,7 @@ id select_type table partitions type pos 1 SIMPLE t2 p0,p4 ALL NULL NULL NULL NULL 910 Using where explain partitions select * from t2 where (a > 100 AND a < 600); id select_type table partitions type possible_keys key key_len ref rows Extra -1 SIMPLE t2 p0,p1,p2,p3 ALL NULL NULL NULL NULL 910 Using where +1 SIMPLE t2 p0,p1,p2 ALL NULL NULL NULL NULL 910 Using where analyze table t2; Table Op Msg_type Msg_text test.t2 analyze status OK === modified file 'mysql-test/suite/pbxt/t/partition_error.test' --- a/mysql-test/suite/pbxt/t/partition_error.test 2009-04-02 10:03:14 +0000 +++ b/mysql-test/suite/pbxt/t/partition_error.test 2010-03-09 15:03:54 +0000 @@ -421,7 +421,7 @@ partitions 2 # # Partition by range, constant partition function not allowed # ---error ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR +--error ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR CREATE TABLE t1 ( a int not null, b int not null, @@ -636,7 +636,7 @@ partition by list (a); # # Partition by list, constant partition function not allowed # ---error ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR +--error ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR CREATE TABLE t1 ( a int not null, b int not null, === modified file 'sql/item_subselect.cc' --- a/sql/item_subselect.cc 2010-01-15 15:27:55 +0000 +++ b/sql/item_subselect.cc 2010-03-09 15:03:54 +0000 @@ -39,7 +39,8 @@ inline Item * and_items(Item* cond, Item Item_subselect::Item_subselect(): Item_result_field(), value_assigned(0), thd(0), substitution(0), engine(0), old_engine(0), used_tables_cache(0), have_to_be_excluded(0), - const_item_cache(1), in_fix_fields(0), engine_changed(0), changed(0), is_correlated(FALSE) + const_item_cache(1), in_fix_fields(0), eliminated(FALSE), + engine_changed(0), changed(0), is_correlated(FALSE) { with_subselect= 1; reset(); @@ -431,6 +432,7 @@ void Item_maxmin_subselect::print(String void Item_singlerow_subselect::reset() { + eliminated= FALSE; null_value= 1; if (value) value->null_value= 1; === modified file 'sql/item_subselect.h' --- a/sql/item_subselect.h 2010-01-15 15:27:55 +0000 +++ b/sql/item_subselect.h 2010-03-09 15:03:54 +0000 @@ -90,6 +90,7 @@ public: void cleanup(); virtual void reset() { + eliminated= FALSE; null_value= 1; } virtual trans_res select_transformer(JOIN *join); @@ -235,6 +236,7 @@ public: subs_type substype() { return EXISTS_SUBS; } void reset() { + eliminated= FALSE; value= 0; } @@ -306,6 +308,7 @@ public: subs_type substype() { return IN_SUBS; } void reset() { + eliminated= FALSE; value= 0; null_value= 0; was_null= 0; === modified file 'sql/sql_partition.cc' --- a/sql/sql_partition.cc 2010-03-04 08:03:07 +0000 +++ b/sql/sql_partition.cc 2010-03-09 15:03:54 +0000 @@ -3019,8 +3019,9 @@ uint32 get_partition_id_range_for_endpoi In case of PARTITION p VALUES LESS THAN MAXVALUE the maximum value is in the current partition. */ - if (part_func_value == part_end_val && - (loc_part_id < max_partition || !part_info->defined_max_value)) + if (part_func_value > part_end_val || + (part_func_value == part_end_val && + (loc_part_id < max_partition || !part_info->defined_max_value))) loc_part_id++; } else === modified file 'sql/table.cc' --- a/sql/table.cc 2010-03-04 08:03:07 +0000 +++ b/sql/table.cc 2010-03-09 15:03:54 +0000 @@ -1847,8 +1847,8 @@ int open_table_from_share(THD *thd, TABL { if (work_part_info_used) tmp= fix_partition_func(thd, outparam, is_create_table); - outparam->part_info->item_free_list= part_func_arena.free_list; } + outparam->part_info->item_free_list= part_func_arena.free_list; partititon_err: if (tmp) {

1 0

[Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2823)
by knielsen＠knielsen-hq.org 09 Mar '10

09 Mar '10

#At lp:maria 2823 knielsen(a)knielsen-hq.org 2010-03-09 A number of after-merge fixes following merge of MySQL 5.1.44 into MariaDB. Bug#46949: memory leak with failed alter table to create partitions based on extract() Bug#51830: Incorrect partition pruning on range partition (regression) Fixed valgrind failure in select_describe(), read of uninitialized Item_subselect::eliminated. PBXT test file updates to reflect changes done in MySQL. modified: mysql-test/suite/pbxt/r/partition_error.result mysql-test/suite/pbxt/r/partition_pruning.result mysql-test/suite/pbxt/t/partition_error.test sql/item_subselect.cc sql/item_subselect.h sql/sql_partition.cc sql/table.cc per-file messages: mysql-test/suite/pbxt/r/partition_error.result Result file update following MySQL 5.1.44 changes. mysql-test/suite/pbxt/r/partition_pruning.result Result file update following MySQL 5.1.44 changes. mysql-test/suite/pbxt/t/partition_error.test Test file update following MySQL 5.1.44 changes. sql/item_subselect.cc Fixed valgrind failure in select_describe(), read of uninitialized Item_subselect::eliminated: - it turns out we can call select_describe() without having fixed subquery items for child subselects. These are not the kind of subqueries that we could eliminate, so the fix is to ensure that item_subselect->eliminated==FALSE even before fix_fields is called. Also added code to reset item_subselect->eliminated back to FALSE in Item::reset() call. sql/item_subselect.h Fixed valgrind failure in select_describe(), read of uninitialized Item_subselect::eliminated: - it turns out we can call select_describe() without having fixed subquery items for child subselects. These are not the kind of subqueries that we could eliminate, so the fix is to ensure that item_subselect->eliminated==FALSE even before fix_fields is called. Also added code to reset item_subselect->eliminated back to FALSE in Item::reset() call. sql/sql_partition.cc Fix Bug#51830: Revert part of the patch for Bug#49742, which caused the regression. sql/table.cc Fix Bug#46949: memory leak in failed ALTER TABLE with partitioning. === modified file 'mysql-test/suite/pbxt/r/partition_error.result' --- a/mysql-test/suite/pbxt/r/partition_error.result 2009-04-02 10:03:14 +0000 +++ b/mysql-test/suite/pbxt/r/partition_error.result 2010-03-09 15:03:54 +0000 @@ -107,7 +107,7 @@ primary key(a,b)) partition by hash (rand(a)) partitions 2 (partition x1, partition x2); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ') +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ') partitions 2 (partition x1, partition x2)' at line 6 CREATE TABLE t1 ( @@ -118,7 +118,7 @@ primary key(a,b)) partition by range (rand(a)) partitions 2 (partition x1 values less than (0), partition x2 values less than (2)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ') +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ') partitions 2 (partition x1 values less than (0), partition x2 values less than' at line 6 CREATE TABLE t1 ( @@ -129,7 +129,7 @@ primary key(a,b)) partition by list (rand(a)) partitions 2 (partition x1 values in (1), partition x2 values in (2)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ') +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ') partitions 2 (partition x1 values in (1), partition x2 values in (2))' at line 6 CREATE TABLE t1 ( @@ -244,7 +244,7 @@ c int not null, primary key (a,b)) partition by key (a) subpartition by hash (rand(a+b)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 7 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 7 CREATE TABLE t1 ( a int not null, b int not null, @@ -341,7 +341,7 @@ partition by range (3+4) partitions 2 (partition x1 values less than (4) tablespace ts1, partition x2 values less than (8) tablespace ts2); -ERROR HY000: Constant/Random expression in (sub)partitioning function is not allowed +ERROR HY000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed CREATE TABLE t1 ( a int not null, b int not null, @@ -511,7 +511,7 @@ partition by list (3+4) partitions 2 (partition x1 values in (4) tablespace ts1, partition x2 values in (8) tablespace ts2); -ERROR HY000: Constant/Random expression in (sub)partitioning function is not allowed +ERROR HY000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed CREATE TABLE t1 ( a int not null, b int not null, @@ -603,13 +603,13 @@ partition by range (ascii(v)) ERROR HY000: This partition function is not allowed create table t1 (a int) partition by hash (rand(a)); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 2 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 2 create table t1 (a int) partition by hash(CURTIME() + a); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 2 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 2 create table t1 (a int) partition by hash (NOW()+a); -ERROR 42000: Constant/Random expression in (sub)partitioning function is not allowed near ')' at line 2 +ERROR 42000: Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed near ')' at line 2 create table t1 (a int) partition by hash (extract(hour from convert_tz(a, '+00:00', '+00:00'))); ERROR HY000: This partition function is not allowed === modified file 'mysql-test/suite/pbxt/r/partition_pruning.result' --- a/mysql-test/suite/pbxt/r/partition_pruning.result 2009-08-17 15:57:58 +0000 +++ b/mysql-test/suite/pbxt/r/partition_pruning.result 2010-03-09 15:03:54 +0000 @@ -527,7 +527,7 @@ id select_type table partitions type pos 1 SIMPLE t2 p0,p4 ALL NULL NULL NULL NULL 910 Using where explain partitions select * from t2 where (a > 100 AND a < 600); id select_type table partitions type possible_keys key key_len ref rows Extra -1 SIMPLE t2 p0,p1,p2,p3 ALL NULL NULL NULL NULL 910 Using where +1 SIMPLE t2 p0,p1,p2 ALL NULL NULL NULL NULL 910 Using where analyze table t2; Table Op Msg_type Msg_text test.t2 analyze status OK === modified file 'mysql-test/suite/pbxt/t/partition_error.test' --- a/mysql-test/suite/pbxt/t/partition_error.test 2009-04-02 10:03:14 +0000 +++ b/mysql-test/suite/pbxt/t/partition_error.test 2010-03-09 15:03:54 +0000 @@ -421,7 +421,7 @@ partitions 2 # # Partition by range, constant partition function not allowed # ---error ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR +--error ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR CREATE TABLE t1 ( a int not null, b int not null, @@ -636,7 +636,7 @@ partition by list (a); # # Partition by list, constant partition function not allowed # ---error ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR +--error ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR CREATE TABLE t1 ( a int not null, b int not null, === modified file 'sql/item_subselect.cc' --- a/sql/item_subselect.cc 2010-01-15 15:27:55 +0000 +++ b/sql/item_subselect.cc 2010-03-09 15:03:54 +0000 @@ -39,7 +39,8 @@ inline Item * and_items(Item* cond, Item Item_subselect::Item_subselect(): Item_result_field(), value_assigned(0), thd(0), substitution(0), engine(0), old_engine(0), used_tables_cache(0), have_to_be_excluded(0), - const_item_cache(1), in_fix_fields(0), engine_changed(0), changed(0), is_correlated(FALSE) + const_item_cache(1), in_fix_fields(0), eliminated(FALSE), + engine_changed(0), changed(0), is_correlated(FALSE) { with_subselect= 1; reset(); @@ -431,6 +432,7 @@ void Item_maxmin_subselect::print(String void Item_singlerow_subselect::reset() { + eliminated= FALSE; null_value= 1; if (value) value->null_value= 1; === modified file 'sql/item_subselect.h' --- a/sql/item_subselect.h 2010-01-15 15:27:55 +0000 +++ b/sql/item_subselect.h 2010-03-09 15:03:54 +0000 @@ -90,6 +90,7 @@ public: void cleanup(); virtual void reset() { + eliminated= FALSE; null_value= 1; } virtual trans_res select_transformer(JOIN *join); @@ -235,6 +236,7 @@ public: subs_type substype() { return EXISTS_SUBS; } void reset() { + eliminated= FALSE; value= 0; } @@ -306,6 +308,7 @@ public: subs_type substype() { return IN_SUBS; } void reset() { + eliminated= FALSE; value= 0; null_value= 0; was_null= 0; === modified file 'sql/sql_partition.cc' --- a/sql/sql_partition.cc 2010-03-04 08:03:07 +0000 +++ b/sql/sql_partition.cc 2010-03-09 15:03:54 +0000 @@ -3019,8 +3019,9 @@ uint32 get_partition_id_range_for_endpoi In case of PARTITION p VALUES LESS THAN MAXVALUE the maximum value is in the current partition. */ - if (part_func_value == part_end_val && - (loc_part_id < max_partition || !part_info->defined_max_value)) + if (part_func_value > part_end_val || + (part_func_value == part_end_val && + (loc_part_id < max_partition || !part_info->defined_max_value))) loc_part_id++; } else === modified file 'sql/table.cc' --- a/sql/table.cc 2010-03-04 08:03:07 +0000 +++ b/sql/table.cc 2010-03-09 15:03:54 +0000 @@ -1847,8 +1847,8 @@ int open_table_from_share(THD *thd, TABL { if (work_part_info_used) tmp= fix_partition_func(thd, outparam, is_create_table); - outparam->part_info->item_free_list= part_func_arena.free_list; } + outparam->part_info->item_free_list= part_func_arena.free_list; partititon_err: if (tmp) {

1 0

[Maria-developers] New (by Serg): pluggable authentication (101)
by worklog-noreply＠askmonty.org 09 Mar '10

09 Mar '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: pluggable authentication CREATION DATE..: Tue, 09 Mar 2010, 14:58 SUPERVISOR.....: Sergei IMPLEMENTOR....: Sergei COPIES TO......: CATEGORY.......: Server-Sprint TASK ID........: 101 (http://askmonty.org/worklog/?tid=101) VERSION........: Server-5.2 STATUS.........: Code-Review PRIORITY.......: 90 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: push the pluggable authentication feature https://code.launchpad.net/~maria-captains/maria/5.2-pluggable-auth ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] New (by Serg): pluggable authentication (101)
by worklog-noreply＠askmonty.org 09 Mar '10

09 Mar '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: pluggable authentication CREATION DATE..: Tue, 09 Mar 2010, 14:58 SUPERVISOR.....: Sergei IMPLEMENTOR....: Sergei COPIES TO......: CATEGORY.......: Server-Sprint TASK ID........: 101 (http://askmonty.org/worklog/?tid=101) VERSION........: Server-5.2 STATUS.........: Code-Review PRIORITY.......: 90 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: push the pluggable authentication feature https://code.launchpad.net/~maria-captains/maria/5.2-pluggable-auth ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Updated (by Knielsen): Enable the use of libstdc++ in MariaDB (63)
by worklog-noreply＠askmonty.org 09 Mar '10

09 Mar '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Enable the use of libstdc++ in MariaDB CREATION DATE..: Wed, 11 Nov 2009, 13:19 SUPERVISOR.....: Monty IMPLEMENTOR....: Knielsen COPIES TO......: CATEGORY.......: Server-Sprint TASK ID........: 63 (http://askmonty.org/worklog/?tid=63) VERSION........: Server-5.2 STATUS.........: Complete PRIORITY.......: 60 WORKED HOURS...: 4 ESTIMATE.......: 10 (hours remain) ORIG. ESTIMATE.: 10 PROGRESS NOTES: -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- Category updated. --- /tmp/wklog.63.old.19705 2010-03-09 14:34:47.000000000 +0000 +++ /tmp/wklog.63.new.19705 2010-03-09 14:34:47.000000000 +0000 @@ -1 +1 @@ -Server-BackLog +Server-Sprint -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- Status updated. --- /tmp/wklog.63.old.19705 2010-03-09 14:34:47.000000000 +0000 +++ /tmp/wklog.63.new.19705 2010-03-09 14:34:47.000000000 +0000 @@ -1 +1 @@ -Assigned +Complete -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- High Level Description modified. --- /tmp/wklog.63.old.19695 2010-03-09 14:34:21.000000000 +0000 +++ /tmp/wklog.63.new.19695 2010-03-09 14:34:21.000000000 +0000 @@ -12,3 +12,11 @@ except that it might introduce a problem for bintar packages with an external dependency on libstdc++. +The conclusion on this worklog is that the solution is just to build with +CXX=g++. This solves the problem, and after research is considered to have no +serious bad consequences. + +Since this is a future build/packaging issue, there is nothing to be actually +done in the code for this worklog. Once we merge an actual plugin into the main +source tree we may need to update the BUILD/* scripts to default to CXX=g++ if +needed. -=-=(Knielsen - Sat, 27 Feb 2010, 16:02)=-=- Status updated. --- /tmp/wklog.63.old.30948 2010-02-27 16:02:20.000000000 +0000 +++ /tmp/wklog.63.new.30948 2010-02-27 16:02:20.000000000 +0000 @@ -1 +1 @@ -Un-Assigned +Assigned -=-=(Knielsen - Thu, 14 Jan 2010, 13:46)=-=- Research and updated description Worked 4 hours and estimate 10 hours remain (original estimate increased by 14 hours). -=-=(Knielsen - Thu, 14 Jan 2010, 13:45)=-=- High-Level Specification modified. --- /tmp/wklog.63.old.13967 2010-01-14 11:45:49.000000000 +0000 +++ /tmp/wklog.63.new.13967 2010-01-14 11:45:49.000000000 +0000 @@ -1 +1,37 @@ +I did some investigation into this. + +The simple way to do this is to simply use g++ to link C++ objects. So this +issue is really restricted to GCC compilation where we by default prefer to +link with gcc even for C++ code. So this means building with + + CXX=g++ + +The consequences of doing this for the binaries is the addition of two +additional run-time .so dependencies: libstdc++.so and libgcc_s.so. + +It still needs to be investigated if these additional dependencies are a +problem for binary tarball packages, or if the ABI for those libraries are now +as stable as libc.so. + +The libgcc_s.so is needed as a dependency to support exceptions between +different object files, as they need to use the same code for stack unwinding. +libstdc++.so is of course needed for access to C++ runtime. + +I researched into the possibility to instead link only specific plugins with +g++, and continue to link the rest of the server with gcc. Unfortunately, this +seems really hard to do in a proper way due to the way autotools works. At +configure time, a script ./libtool is created with hardcoded compiler commands +derived from $CC and $CXX. This script is then used to do the actual linking +in Makefiles generated by Automake. I thus did not find a way to change the +linker command on a per-makefile basis, as libtool is global to the project. + +One option would be to use separate configure.in for plugins, but this is +quite an intrusive change. + +My conclusion is that the best way is to start using g++ for linking the +entire server. This is no problem for binaries made for a specific +distribution (Ubuntu, Debian, Centos), where the dependencies are handled by +the package manager. If it is a big problem for binary tarball releases, at +worst we can build multiple binary tarball releases for the different library +versions we need to support. -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Version updated. --- /tmp/wklog.63.old.19522 2010-01-12 16:26:23.000000000 +0200 +++ /tmp/wklog.63.new.19522 2010-01-12 16:26:23.000000000 +0200 @@ -1 +1 @@ -Connector/.NET-5.2 +Server-5.2 -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Category updated. --- /tmp/wklog.63.old.19506 2010-01-12 16:26:15.000000000 +0200 +++ /tmp/wklog.63.new.19506 2010-01-12 16:26:15.000000000 +0200 @@ -1 +1 @@ -Server-RawIdeaBin +Server-BackLog DESCRIPTION: Enable the use of libstdc++ in MariaDB. As time goes on, more and more plugins and external code/library will need linking to libstdc++ for stuff it uses. I have already seen this happen several times, with extra work needed to integrate things properly. It would be nice to have a general solution for this so that it is not necessary to spend time on individual solutions in each case. It also needs to be considered what the impact of this will be for the server in terms of binary compatibility, performance etc. I think it should be mostly ok, except that it might introduce a problem for bintar packages with an external dependency on libstdc++. The conclusion on this worklog is that the solution is just to build with CXX=g++. This solves the problem, and after research is considered to have no serious bad consequences. Since this is a future build/packaging issue, there is nothing to be actually done in the code for this worklog. Once we merge an actual plugin into the main source tree we may need to update the BUILD/* scripts to default to CXX=g++ if needed. HIGH-LEVEL SPECIFICATION: I did some investigation into this. The simple way to do this is to simply use g++ to link C++ objects. So this issue is really restricted to GCC compilation where we by default prefer to link with gcc even for C++ code. So this means building with CXX=g++ The consequences of doing this for the binaries is the addition of two additional run-time .so dependencies: libstdc++.so and libgcc_s.so. It still needs to be investigated if these additional dependencies are a problem for binary tarball packages, or if the ABI for those libraries are now as stable as libc.so. The libgcc_s.so is needed as a dependency to support exceptions between different object files, as they need to use the same code for stack unwinding. libstdc++.so is of course needed for access to C++ runtime. I researched into the possibility to instead link only specific plugins with g++, and continue to link the rest of the server with gcc. Unfortunately, this seems really hard to do in a proper way due to the way autotools works. At configure time, a script ./libtool is created with hardcoded compiler commands derived from $CC and $CXX. This script is then used to do the actual linking in Makefiles generated by Automake. I thus did not find a way to change the linker command on a per-makefile basis, as libtool is global to the project. One option would be to use separate configure.in for plugins, but this is quite an intrusive change. My conclusion is that the best way is to start using g++ for linking the entire server. This is no problem for binaries made for a specific distribution (Ubuntu, Debian, Centos), where the dependencies are handled by the package manager. If it is a big problem for binary tarball releases, at worst we can build multiple binary tarball releases for the different library versions we need to support. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Updated (by Knielsen): Enable the use of libstdc++ in MariaDB (63)
by worklog-noreply＠askmonty.org 09 Mar '10

09 Mar '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Enable the use of libstdc++ in MariaDB CREATION DATE..: Wed, 11 Nov 2009, 13:19 SUPERVISOR.....: Monty IMPLEMENTOR....: Knielsen COPIES TO......: CATEGORY.......: Server-Sprint TASK ID........: 63 (http://askmonty.org/worklog/?tid=63) VERSION........: Server-5.2 STATUS.........: Complete PRIORITY.......: 60 WORKED HOURS...: 4 ESTIMATE.......: 10 (hours remain) ORIG. ESTIMATE.: 10 PROGRESS NOTES: -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- Category updated. --- /tmp/wklog.63.old.19705 2010-03-09 14:34:47.000000000 +0000 +++ /tmp/wklog.63.new.19705 2010-03-09 14:34:47.000000000 +0000 @@ -1 +1 @@ -Server-BackLog +Server-Sprint -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- Status updated. --- /tmp/wklog.63.old.19705 2010-03-09 14:34:47.000000000 +0000 +++ /tmp/wklog.63.new.19705 2010-03-09 14:34:47.000000000 +0000 @@ -1 +1 @@ -Assigned +Complete -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- High Level Description modified. --- /tmp/wklog.63.old.19695 2010-03-09 14:34:21.000000000 +0000 +++ /tmp/wklog.63.new.19695 2010-03-09 14:34:21.000000000 +0000 @@ -12,3 +12,11 @@ except that it might introduce a problem for bintar packages with an external dependency on libstdc++. +The conclusion on this worklog is that the solution is just to build with +CXX=g++. This solves the problem, and after research is considered to have no +serious bad consequences. + +Since this is a future build/packaging issue, there is nothing to be actually +done in the code for this worklog. Once we merge an actual plugin into the main +source tree we may need to update the BUILD/* scripts to default to CXX=g++ if +needed. -=-=(Knielsen - Sat, 27 Feb 2010, 16:02)=-=- Status updated. --- /tmp/wklog.63.old.30948 2010-02-27 16:02:20.000000000 +0000 +++ /tmp/wklog.63.new.30948 2010-02-27 16:02:20.000000000 +0000 @@ -1 +1 @@ -Un-Assigned +Assigned -=-=(Knielsen - Thu, 14 Jan 2010, 13:46)=-=- Research and updated description Worked 4 hours and estimate 10 hours remain (original estimate increased by 14 hours). -=-=(Knielsen - Thu, 14 Jan 2010, 13:45)=-=- High-Level Specification modified. --- /tmp/wklog.63.old.13967 2010-01-14 11:45:49.000000000 +0000 +++ /tmp/wklog.63.new.13967 2010-01-14 11:45:49.000000000 +0000 @@ -1 +1,37 @@ +I did some investigation into this. + +The simple way to do this is to simply use g++ to link C++ objects. So this +issue is really restricted to GCC compilation where we by default prefer to +link with gcc even for C++ code. So this means building with + + CXX=g++ + +The consequences of doing this for the binaries is the addition of two +additional run-time .so dependencies: libstdc++.so and libgcc_s.so. + +It still needs to be investigated if these additional dependencies are a +problem for binary tarball packages, or if the ABI for those libraries are now +as stable as libc.so. + +The libgcc_s.so is needed as a dependency to support exceptions between +different object files, as they need to use the same code for stack unwinding. +libstdc++.so is of course needed for access to C++ runtime. + +I researched into the possibility to instead link only specific plugins with +g++, and continue to link the rest of the server with gcc. Unfortunately, this +seems really hard to do in a proper way due to the way autotools works. At +configure time, a script ./libtool is created with hardcoded compiler commands +derived from $CC and $CXX. This script is then used to do the actual linking +in Makefiles generated by Automake. I thus did not find a way to change the +linker command on a per-makefile basis, as libtool is global to the project. + +One option would be to use separate configure.in for plugins, but this is +quite an intrusive change. + +My conclusion is that the best way is to start using g++ for linking the +entire server. This is no problem for binaries made for a specific +distribution (Ubuntu, Debian, Centos), where the dependencies are handled by +the package manager. If it is a big problem for binary tarball releases, at +worst we can build multiple binary tarball releases for the different library +versions we need to support. -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Version updated. --- /tmp/wklog.63.old.19522 2010-01-12 16:26:23.000000000 +0200 +++ /tmp/wklog.63.new.19522 2010-01-12 16:26:23.000000000 +0200 @@ -1 +1 @@ -Connector/.NET-5.2 +Server-5.2 -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Category updated. --- /tmp/wklog.63.old.19506 2010-01-12 16:26:15.000000000 +0200 +++ /tmp/wklog.63.new.19506 2010-01-12 16:26:15.000000000 +0200 @@ -1 +1 @@ -Server-RawIdeaBin +Server-BackLog DESCRIPTION: Enable the use of libstdc++ in MariaDB. As time goes on, more and more plugins and external code/library will need linking to libstdc++ for stuff it uses. I have already seen this happen several times, with extra work needed to integrate things properly. It would be nice to have a general solution for this so that it is not necessary to spend time on individual solutions in each case. It also needs to be considered what the impact of this will be for the server in terms of binary compatibility, performance etc. I think it should be mostly ok, except that it might introduce a problem for bintar packages with an external dependency on libstdc++. The conclusion on this worklog is that the solution is just to build with CXX=g++. This solves the problem, and after research is considered to have no serious bad consequences. Since this is a future build/packaging issue, there is nothing to be actually done in the code for this worklog. Once we merge an actual plugin into the main source tree we may need to update the BUILD/* scripts to default to CXX=g++ if needed. HIGH-LEVEL SPECIFICATION: I did some investigation into this. The simple way to do this is to simply use g++ to link C++ objects. So this issue is really restricted to GCC compilation where we by default prefer to link with gcc even for C++ code. So this means building with CXX=g++ The consequences of doing this for the binaries is the addition of two additional run-time .so dependencies: libstdc++.so and libgcc_s.so. It still needs to be investigated if these additional dependencies are a problem for binary tarball packages, or if the ABI for those libraries are now as stable as libc.so. The libgcc_s.so is needed as a dependency to support exceptions between different object files, as they need to use the same code for stack unwinding. libstdc++.so is of course needed for access to C++ runtime. I researched into the possibility to instead link only specific plugins with g++, and continue to link the rest of the server with gcc. Unfortunately, this seems really hard to do in a proper way due to the way autotools works. At configure time, a script ./libtool is created with hardcoded compiler commands derived from $CC and $CXX. This script is then used to do the actual linking in Makefiles generated by Automake. I thus did not find a way to change the linker command on a per-makefile basis, as libtool is global to the project. One option would be to use separate configure.in for plugins, but this is quite an intrusive change. My conclusion is that the best way is to start using g++ for linking the entire server. This is no problem for binaries made for a specific distribution (Ubuntu, Debian, Centos), where the dependencies are handled by the package manager. If it is a big problem for binary tarball releases, at worst we can build multiple binary tarball releases for the different library versions we need to support. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Updated (by Knielsen): Enable the use of libstdc++ in MariaDB (63)
by worklog-noreply＠askmonty.org 09 Mar '10

09 Mar '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Enable the use of libstdc++ in MariaDB CREATION DATE..: Wed, 11 Nov 2009, 13:19 SUPERVISOR.....: Monty IMPLEMENTOR....: Knielsen COPIES TO......: CATEGORY.......: Server-BackLog TASK ID........: 63 (http://askmonty.org/worklog/?tid=63) VERSION........: Server-5.2 STATUS.........: Assigned PRIORITY.......: 60 WORKED HOURS...: 4 ESTIMATE.......: 10 (hours remain) ORIG. ESTIMATE.: 10 PROGRESS NOTES: -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- High Level Description modified. --- /tmp/wklog.63.old.19695 2010-03-09 14:34:21.000000000 +0000 +++ /tmp/wklog.63.new.19695 2010-03-09 14:34:21.000000000 +0000 @@ -12,3 +12,11 @@ except that it might introduce a problem for bintar packages with an external dependency on libstdc++. +The conclusion on this worklog is that the solution is just to build with +CXX=g++. This solves the problem, and after research is considered to have no +serious bad consequences. + +Since this is a future build/packaging issue, there is nothing to be actually +done in the code for this worklog. Once we merge an actual plugin into the main +source tree we may need to update the BUILD/* scripts to default to CXX=g++ if +needed. -=-=(Knielsen - Sat, 27 Feb 2010, 16:02)=-=- Status updated. --- /tmp/wklog.63.old.30948 2010-02-27 16:02:20.000000000 +0000 +++ /tmp/wklog.63.new.30948 2010-02-27 16:02:20.000000000 +0000 @@ -1 +1 @@ -Un-Assigned +Assigned -=-=(Knielsen - Thu, 14 Jan 2010, 13:46)=-=- Research and updated description Worked 4 hours and estimate 10 hours remain (original estimate increased by 14 hours). -=-=(Knielsen - Thu, 14 Jan 2010, 13:45)=-=- High-Level Specification modified. --- /tmp/wklog.63.old.13967 2010-01-14 11:45:49.000000000 +0000 +++ /tmp/wklog.63.new.13967 2010-01-14 11:45:49.000000000 +0000 @@ -1 +1,37 @@ +I did some investigation into this. + +The simple way to do this is to simply use g++ to link C++ objects. So this +issue is really restricted to GCC compilation where we by default prefer to +link with gcc even for C++ code. So this means building with + + CXX=g++ + +The consequences of doing this for the binaries is the addition of two +additional run-time .so dependencies: libstdc++.so and libgcc_s.so. + +It still needs to be investigated if these additional dependencies are a +problem for binary tarball packages, or if the ABI for those libraries are now +as stable as libc.so. + +The libgcc_s.so is needed as a dependency to support exceptions between +different object files, as they need to use the same code for stack unwinding. +libstdc++.so is of course needed for access to C++ runtime. + +I researched into the possibility to instead link only specific plugins with +g++, and continue to link the rest of the server with gcc. Unfortunately, this +seems really hard to do in a proper way due to the way autotools works. At +configure time, a script ./libtool is created with hardcoded compiler commands +derived from $CC and $CXX. This script is then used to do the actual linking +in Makefiles generated by Automake. I thus did not find a way to change the +linker command on a per-makefile basis, as libtool is global to the project. + +One option would be to use separate configure.in for plugins, but this is +quite an intrusive change. + +My conclusion is that the best way is to start using g++ for linking the +entire server. This is no problem for binaries made for a specific +distribution (Ubuntu, Debian, Centos), where the dependencies are handled by +the package manager. If it is a big problem for binary tarball releases, at +worst we can build multiple binary tarball releases for the different library +versions we need to support. -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Version updated. --- /tmp/wklog.63.old.19522 2010-01-12 16:26:23.000000000 +0200 +++ /tmp/wklog.63.new.19522 2010-01-12 16:26:23.000000000 +0200 @@ -1 +1 @@ -Connector/.NET-5.2 +Server-5.2 -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Category updated. --- /tmp/wklog.63.old.19506 2010-01-12 16:26:15.000000000 +0200 +++ /tmp/wklog.63.new.19506 2010-01-12 16:26:15.000000000 +0200 @@ -1 +1 @@ -Server-RawIdeaBin +Server-BackLog DESCRIPTION: Enable the use of libstdc++ in MariaDB. As time goes on, more and more plugins and external code/library will need linking to libstdc++ for stuff it uses. I have already seen this happen several times, with extra work needed to integrate things properly. It would be nice to have a general solution for this so that it is not necessary to spend time on individual solutions in each case. It also needs to be considered what the impact of this will be for the server in terms of binary compatibility, performance etc. I think it should be mostly ok, except that it might introduce a problem for bintar packages with an external dependency on libstdc++. The conclusion on this worklog is that the solution is just to build with CXX=g++. This solves the problem, and after research is considered to have no serious bad consequences. Since this is a future build/packaging issue, there is nothing to be actually done in the code for this worklog. Once we merge an actual plugin into the main source tree we may need to update the BUILD/* scripts to default to CXX=g++ if needed. HIGH-LEVEL SPECIFICATION: I did some investigation into this. The simple way to do this is to simply use g++ to link C++ objects. So this issue is really restricted to GCC compilation where we by default prefer to link with gcc even for C++ code. So this means building with CXX=g++ The consequences of doing this for the binaries is the addition of two additional run-time .so dependencies: libstdc++.so and libgcc_s.so. It still needs to be investigated if these additional dependencies are a problem for binary tarball packages, or if the ABI for those libraries are now as stable as libc.so. The libgcc_s.so is needed as a dependency to support exceptions between different object files, as they need to use the same code for stack unwinding. libstdc++.so is of course needed for access to C++ runtime. I researched into the possibility to instead link only specific plugins with g++, and continue to link the rest of the server with gcc. Unfortunately, this seems really hard to do in a proper way due to the way autotools works. At configure time, a script ./libtool is created with hardcoded compiler commands derived from $CC and $CXX. This script is then used to do the actual linking in Makefiles generated by Automake. I thus did not find a way to change the linker command on a per-makefile basis, as libtool is global to the project. One option would be to use separate configure.in for plugins, but this is quite an intrusive change. My conclusion is that the best way is to start using g++ for linking the entire server. This is no problem for binaries made for a specific distribution (Ubuntu, Debian, Centos), where the dependencies are handled by the package manager. If it is a big problem for binary tarball releases, at worst we can build multiple binary tarball releases for the different library versions we need to support. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Updated (by Knielsen): Enable the use of libstdc++ in MariaDB (63)
by worklog-noreply＠askmonty.org 09 Mar '10

09 Mar '10

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Enable the use of libstdc++ in MariaDB CREATION DATE..: Wed, 11 Nov 2009, 13:19 SUPERVISOR.....: Monty IMPLEMENTOR....: Knielsen COPIES TO......: CATEGORY.......: Server-BackLog TASK ID........: 63 (http://askmonty.org/worklog/?tid=63) VERSION........: Server-5.2 STATUS.........: Assigned PRIORITY.......: 60 WORKED HOURS...: 4 ESTIMATE.......: 10 (hours remain) ORIG. ESTIMATE.: 10 PROGRESS NOTES: -=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=- High Level Description modified. --- /tmp/wklog.63.old.19695 2010-03-09 14:34:21.000000000 +0000 +++ /tmp/wklog.63.new.19695 2010-03-09 14:34:21.000000000 +0000 @@ -12,3 +12,11 @@ except that it might introduce a problem for bintar packages with an external dependency on libstdc++. +The conclusion on this worklog is that the solution is just to build with +CXX=g++. This solves the problem, and after research is considered to have no +serious bad consequences. + +Since this is a future build/packaging issue, there is nothing to be actually +done in the code for this worklog. Once we merge an actual plugin into the main +source tree we may need to update the BUILD/* scripts to default to CXX=g++ if +needed. -=-=(Knielsen - Sat, 27 Feb 2010, 16:02)=-=- Status updated. --- /tmp/wklog.63.old.30948 2010-02-27 16:02:20.000000000 +0000 +++ /tmp/wklog.63.new.30948 2010-02-27 16:02:20.000000000 +0000 @@ -1 +1 @@ -Un-Assigned +Assigned -=-=(Knielsen - Thu, 14 Jan 2010, 13:46)=-=- Research and updated description Worked 4 hours and estimate 10 hours remain (original estimate increased by 14 hours). -=-=(Knielsen - Thu, 14 Jan 2010, 13:45)=-=- High-Level Specification modified. --- /tmp/wklog.63.old.13967 2010-01-14 11:45:49.000000000 +0000 +++ /tmp/wklog.63.new.13967 2010-01-14 11:45:49.000000000 +0000 @@ -1 +1,37 @@ +I did some investigation into this. + +The simple way to do this is to simply use g++ to link C++ objects. So this +issue is really restricted to GCC compilation where we by default prefer to +link with gcc even for C++ code. So this means building with + + CXX=g++ + +The consequences of doing this for the binaries is the addition of two +additional run-time .so dependencies: libstdc++.so and libgcc_s.so. + +It still needs to be investigated if these additional dependencies are a +problem for binary tarball packages, or if the ABI for those libraries are now +as stable as libc.so. + +The libgcc_s.so is needed as a dependency to support exceptions between +different object files, as they need to use the same code for stack unwinding. +libstdc++.so is of course needed for access to C++ runtime. + +I researched into the possibility to instead link only specific plugins with +g++, and continue to link the rest of the server with gcc. Unfortunately, this +seems really hard to do in a proper way due to the way autotools works. At +configure time, a script ./libtool is created with hardcoded compiler commands +derived from $CC and $CXX. This script is then used to do the actual linking +in Makefiles generated by Automake. I thus did not find a way to change the +linker command on a per-makefile basis, as libtool is global to the project. + +One option would be to use separate configure.in for plugins, but this is +quite an intrusive change. + +My conclusion is that the best way is to start using g++ for linking the +entire server. This is no problem for binaries made for a specific +distribution (Ubuntu, Debian, Centos), where the dependencies are handled by +the package manager. If it is a big problem for binary tarball releases, at +worst we can build multiple binary tarball releases for the different library +versions we need to support. -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Version updated. --- /tmp/wklog.63.old.19522 2010-01-12 16:26:23.000000000 +0200 +++ /tmp/wklog.63.new.19522 2010-01-12 16:26:23.000000000 +0200 @@ -1 +1 @@ -Connector/.NET-5.2 +Server-5.2 -=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=- Category updated. --- /tmp/wklog.63.old.19506 2010-01-12 16:26:15.000000000 +0200 +++ /tmp/wklog.63.new.19506 2010-01-12 16:26:15.000000000 +0200 @@ -1 +1 @@ -Server-RawIdeaBin +Server-BackLog DESCRIPTION: Enable the use of libstdc++ in MariaDB. As time goes on, more and more plugins and external code/library will need linking to libstdc++ for stuff it uses. I have already seen this happen several times, with extra work needed to integrate things properly. It would be nice to have a general solution for this so that it is not necessary to spend time on individual solutions in each case. It also needs to be considered what the impact of this will be for the server in terms of binary compatibility, performance etc. I think it should be mostly ok, except that it might introduce a problem for bintar packages with an external dependency on libstdc++. The conclusion on this worklog is that the solution is just to build with CXX=g++. This solves the problem, and after research is considered to have no serious bad consequences. Since this is a future build/packaging issue, there is nothing to be actually done in the code for this worklog. Once we merge an actual plugin into the main source tree we may need to update the BUILD/* scripts to default to CXX=g++ if needed. HIGH-LEVEL SPECIFICATION: I did some investigation into this. The simple way to do this is to simply use g++ to link C++ objects. So this issue is really restricted to GCC compilation where we by default prefer to link with gcc even for C++ code. So this means building with CXX=g++ The consequences of doing this for the binaries is the addition of two additional run-time .so dependencies: libstdc++.so and libgcc_s.so. It still needs to be investigated if these additional dependencies are a problem for binary tarball packages, or if the ABI for those libraries are now as stable as libc.so. The libgcc_s.so is needed as a dependency to support exceptions between different object files, as they need to use the same code for stack unwinding. libstdc++.so is of course needed for access to C++ runtime. I researched into the possibility to instead link only specific plugins with g++, and continue to link the rest of the server with gcc. Unfortunately, this seems really hard to do in a proper way due to the way autotools works. At configure time, a script ./libtool is created with hardcoded compiler commands derived from $CC and $CXX. This script is then used to do the actual linking in Makefiles generated by Automake. I thus did not find a way to change the linker command on a per-makefile basis, as libtool is global to the project. One option would be to use separate configure.in for plugins, but this is quite an intrusive change. My conclusion is that the best way is to start using g++ for linking the entire server. This is no problem for binaries made for a specific distribution (Ubuntu, Debian, Centos), where the dependencies are handled by the package manager. If it is a big problem for binary tarball releases, at worst we can build multiple binary tarball releases for the different library versions we need to support. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Rev 21: Merged run-sysbench.sh with run-sysbench-myisam.sh in file:///Users/hakan/work/monty_program/mariadb-tools/
by Hakan Kuecuekyilmaz 09 Mar '10

09 Mar '10

At file:///Users/hakan/work/monty_program/mariadb-tools/ ------------------------------------------------------------ revno: 21 revision-id: hakan(a)askmonty.org-20100309142133-07u5qhnsa74is32n parent: hakan(a)askmonty.org-20100309140451-ehuc08gs4x851gtn committer: Hakan Kuecuekyilmaz <hakan(a)askmonty.org> branch nick: mariadb-tools timestamp: Tue 2010-03-09 15:21:33 +0100 message: Merged run-sysbench.sh with run-sysbench-myisam.sh === modified file 'sysbench/run-sysbench-myisam.sh' --- a/sysbench/run-sysbench-myisam.sh 2010-03-09 14:04:29 +0000 +++ b/sysbench/run-sysbench-myisam.sh 2010-03-09 14:21:33 +0000 @@ -82,6 +82,9 @@ # How many times we run each test. LOOP_COUNT=3 +# We need at least 1 GB disk space in our $WORK_DIR. +SPACE_LIMIT=1000000 + SYSBENCH_TESTS="delete.lua \ insert.lua \ oltp_complex_ro.lua \ @@ -101,7 +104,9 @@ --mysql-table-engine=MyISAM \ --mysql-user=root \ --mysql-engine-trx=no \ - --myisam-max-rows=50000000" + --myisam-max-rows=50000000 \ + --rand-init=on \ + --rand-seed=303" # Timeout in seconds for waiting for mysqld to start. TIMEOUT=100 @@ -112,12 +117,26 @@ BASE="${HOME}/work" TEST_DIR="${BASE}/monty_program/sysbench/sysbench/tests/db" RESULT_DIR="${BASE}/sysbench-results" +SYSBENCH_DB_BACKUP="${TEMP_DIR}/sysbench_db" # # Files # BUILD_LOG="${WORK_DIR}/${PRODUCT}_build.log" +# +# Check system. +# +# We should at least have $SPACE_LIMIT in $WORKDIR. +AVAILABLE=$(df $WORK_DIR | grep -v Filesystem | awk '{ print $4 }') + +if [ $AVAILABLE -lt $SPACE_LIMIT ]; then + echo "[ERROR]: We need at least $SPACE_LIMIT space in $WORK_DIR." + echo 'Exiting.' + + exit 1 +fi + if [ ! -d $LOCAL_MASTER ]; then echo "[ERROR]: Supplied local master $LOCAL_MASTER does not exists." echo " Please provide a valid bzr repository." @@ -202,40 +221,72 @@ mkdir ${RESULT_DIR}/${TODAY} mkdir ${RESULT_DIR}/${TODAY}/${PRODUCT} -killall -9 mysqld -rm -rf $DATA_DIR -rm -f $MY_SOCKET -mkdir $DATA_DIR - -sql/mysqld $MYSQL_OPTIONS & - -j=0 -STARTED=-1 -while [ $j -le $TIMEOUT ] - do - $MYSQLADMIN $MYSQLADMIN_OPTIONS ping > /dev/null 2>&1 - if [ $? = 0 ]; then - STARTED=0 +function kill_mysqld { + killall -9 mysqld + rm -rf $DATA_DIR + rm -f $MY_SOCKET + mkdir $DATA_DIR +} + +function start_mysqld { + sql/mysqld $MYSQL_OPTIONS & + + j=0 + STARTED=-1 + while [ $j -le $TIMEOUT ] + do + $MYSQLADMIN $MYSQLADMIN_OPTIONS ping > /dev/null 2>&1 + if [ $? = 0 ]; then + STARTED=0 + + break + fi - break + sleep 1 + j=$(($j + 1)) + done + + if [ $STARTED != 0 ]; then + echo '[ERROR]: Start of mysqld failed.' + echo ' Please check your error log.' + echo ' Exiting.' + + exit 1 fi - - sleep 1 - j=$(($j + 1)) -done - -if [ $STARTED != 0 ]; then - echo '[ERROR]: Start of mysqld failed.' - echo ' Please check your error log.' - echo ' Exiting.' - - exit 1 -fi +} + +# +# Write out configurations used for future refernce. +# +echo $MYSQL_OPTIONS > ${RESULT_DIR}/${TODAY}/${PRODUCT}/mysqld_options.txt +echo $SYSBENCH_OPTIONS > ${RESULT_DIR}/${TODAY}/${PRODUCT}/sysbench_options.txt for SYSBENCH_TEST in $SYSBENCH_TESTS do mkdir ${RESULT_DIR}/${TODAY}/${PRODUCT}/${SYSBENCH_TEST} + kill_mysqld + start_mysqld + $MYSQLADMIN $MYSQLADMIN_OPTIONS create sbtest + if [ $? != 0 ]; then + echo "[ERROR]: Create of sbtest database failed" + echo " Please check your setup." + echo " Exiting" + exit 1 + fi + + echo "[$(date "+%Y-%m-%d %H:%M:%S")] Preparing and loading data for $SYSBENCH_TEST." + SYSBENCH_OPTIONS="${SYSBENCH_OPTIONS} --test=${TEST_DIR}/${SYSBENCH_TEST}" + $SYSBENCH $SYSBENCH_OPTIONS prepare + + $MYSQLADMIN $MYSQLADMIN_OPTIONS shutdown + sync + rm -rf ${SYSBENCH_DB_BACKUP} + mkdir ${SYSBENCH_DB_BACKUP} + + echo "[$(date "+%Y-%m-%d %H:%M:%S")] Copying $DATA_DIR of $SYSBENCH_TEST for later usage." + cp -a ${DATA_DIR}/* ${SYSBENCH_DB_BACKUP}/ + for THREADS in $NUM_THREADS do THIS_RESULT_DIR="${RESULT_DIR}/${TODAY}/${PRODUCT}/${SYSBENCH_TEST}/${THREADS}" @@ -243,23 +294,24 @@ echo "[$(date "+%Y-%m-%d %H:%M:%S")] Running $SYSBENCH_TEST with $THREADS threads and $LOOP_COUNT iterations for $PRODUCT" | tee ${THIS_RESULT_DIR}/results.txt echo '' >> ${THIS_RESULT_DIR}/results.txt + SYSBENCH_OPTIONS="$SYSBENCH_OPTIONS --num-threads=$THREADS" + k=0 while [ $k -lt $LOOP_COUNT ] do - $MYSQLADMIN $MYSQLADMIN_OPTIONS -f drop sbtest - $MYSQLADMIN $MYSQLADMIN_OPTIONS create sbtest - if [ $? != 0 ]; then - echo "[ERROR]: Create of sbtest database failed" - echo " Please check your setup." - echo " Exiting" - exit 1 - fi - - SYSBENCH_OPTIONS="$SYSBENCH_OPTIONS --num-threads=$THREADS --test=${TEST_DIR}/${SYSBENCH_TEST}" - $SYSBENCH $SYSBENCH_OPTIONS prepare - - sync - sleep 3 + echo '' + echo "[$(date "+%Y-%m-%d %H:%M:%S")] Killing mysqld and copying back $DATA_DIR for $SYSBENCH_TEST." + kill_mysqld + cp -a ${SYSBENCH_DB_BACKUP}/* ${DATA_DIR} + + # Clear file system cache. This works only with Linux >= 2.6.16. + # On Mac OS X we can use sync; purge. + sync + echo 3 | $SUDO tee /proc/sys/vm/drop_caches + + echo "[$(date "+%Y-%m-%d %H:%M:%S")] Starting mysqld for running $SYSBENCH_TEST with $THREADS threads and $LOOP_COUNT iterations for $PRODUCT" + start_mysqld + sync $SYSBENCH $SYSBENCH_OPTIONS run > ${THIS_RESULT_DIR}/result${k}.txt 2>&1 @@ -267,6 +319,9 @@ k=$(($k + 1)) done + + echo '' >> ${THIS_RESULT_DIR}/results.txt + echo "[$(date "+%Y-%m-%d %H:%M:%S")] Finnished $SYSBENCH_TEST with $THREADS threads and $LOOP_COUNT iterations for $PRODUCT" | tee -a ${THIS_RESULT_DIR}/results.txt done done

1 0