Re: bk commit into 5.0 tree (tnurnberg:1.2504) BUG#10776

[Joerg Bruehe]

Hi Tatjana,


to me, there seem to be some inconsistencies between your file changes 
and the comments you made:

All your changeset comments refer to AIX 5.2,
but the file changes affect all AIX versions.

More details inline.

Tatjana A Nuernberg wrote:
> Below is the list of changes that have just been committed into a local
> 5.0 repository of tnurnberg. When tnurnberg does a push these changes will
> be propagated to the main repository and, within 24 hours after the
> push, to the public repository.
> For information on how to access the public repository
> see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
> 
> ChangeSet@stripped, 2007-08-01 04:45:02+02:00, tnurnberg@stripped +16
> -0
>   Bug #10776: Failure to compile ndb ReadNodesConf.cpp on AIX 5.2
>   
>   mysqld hasn't been built on AIX with ndb-everything in quite a while.
>   this allowed a variety of changes to be added that broke the AIX build
>   for both the GNU and IBM compilers (but the IBM suite in particular).
>   Changeset lets build to complete on AIX 5.2 for users of the GNU and
>   the IBM suite both. Tudo bem?
> 
>   config/ac-macros/large_file.m4@stripped, 2007-08-01 04:44:54+02:00,
> tnurnberg@stripped +3 -8
>     Bug #10776: Failure to compile ndb ReadNodesConf.cpp on AIX 5.2 (2)
>     
>     we no longer declare anything large-file on AIX.  the
>     GNU C++ compiler declares _LARGE_FILE_API all of its
>     own, and either way we're now pulling in <standards.h>
>     when on AIX, which defines _LARGE_FILE_API (if not
>     already defined).
> 
>   configure.in@stripped, 2007-08-01 04:44:54+02:00, tnurnberg@stripped +6
> -0
>     Bug #10776: Failure to compile ndb ReadNodesConf.cpp on AIX 5.2 (1)
>     
>     build NDB binaries as static on AIX. because that actually
>     *works*.
>     
>     when building dynamic, with the IBM compiler (xlC_r), and
>     the build breaks on AIX due to missing symbols
>     (__vec__delete2 et al.), try adding -lhC to the Makefile.
> 
> 
>   [[...]]
> 
> diff -Nrup a/config/ac-macros/large_file.m4 b/config/ac-macros/large_file.m4
> --- a/config/ac-macros/large_file.m4	2004-12-04 19:48:50 +01:00
> +++ b/config/ac-macros/large_file.m4	2007-08-01 04:44:54 +02:00
> @@ -127,14 +127,9 @@ AC_DEFUN([MYSQL_SYS_LARGEFILE],
>  	hpux10.[2-9][0-9]* | hpux1[1-9]* | hpux[2-9][0-9]*)
>  	  ac_cv_sys_largefile_source=1 ;;
>  	esac])
> -     AC_SYS_LARGEFILE_MACRO_VALUE(_LARGE_FILES,
> -       ac_cv_sys_large_files,
> -       [Large files support on AIX-style hosts.],
> -       [case "$host_os" in
> -	# AIX 4.2 and later
> -	aix4.[2-9]* | aix4.1[0-9]* | aix[5-9].* | aix[1-9][0-9]*)
> -	  ac_cv_sys_large_files=1 ;;
> -	esac])
> +
> +     # AIX 4.2 and later -- do nothing, include standards.h instead.
> +     # this goes for both GNU and IBM C and C++ compilers.

The deleted lines take effect starting from AIX 4.1.
We do not build our 5.0 (and up) on any AIX 4, so it is not important 
for MySQL AB - but we do not test build there, so it is possible your 
change breaks something. Or did you test on our "aix43" host ?

If I get it right, your change does not completely remove 
"ac_cv_sys_large_files" - what about leaving the lines in, and just 
removing the AIX 5 branch from the case brtanch ?

>     fi
>    ])
>  
> diff -Nrup a/configure.in b/configure.in
> --- a/configure.in	2007-06-21 18:28:48 +02:00
> +++ b/configure.in	2007-08-01 04:44:54 +02:00
> @@ -2890,6 +2890,12 @@ then
>    ndb_opt_subdirs="$ndb_opt_subdirs docs"
>    ndb_bin_am_ldflags=""
>  fi
> +# building dynamic breaks on AIX. (If you want to try it and get unresolved
> +# __vec__delete2 and some such, try linking against libhC.)
> +case "$host_os" in
> +  aix3.* | aix4.0.* | aix4.1.*) ;;
> +  *) ndb_bin_am_ldflags="-static";;
> +esac

Is it worth caring about these old versions ?
We don't have them in our environment, AFAIK.

>  AC_SUBST([ndb_bin_am_ldflags])
>  AC_SUBST([ndb_opt_subdirs])
>  
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/benchronja.cpp b/ndb/test/ndbapi/benchronja.cpp
> [[...]]
> +#define NDB_MAXTHREADS 256
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/flexAsynch.cpp b/ndb/test/ndbapi/flexAsynch.cpp
> [[...]]
> +#define NDB_MAXTHREADS 128
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/flexHammer.cpp b/ndb/test/ndbapi/flexHammer.cpp
> [[...]]
> +#define NDB_MAXTHREADS 256
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/flexScan.cpp b/ndb/test/ndbapi/flexScan.cpp
> [[...]]
> +#define NDB_MAXTHREADS 256
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/flexTT.cpp b/ndb/test/ndbapi/flexTT.cpp
> [[...]]
> +#define NDB_MAXTHREADS 128
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/flexTimedAsynch.cpp
> b/ndb/test/ndbapi/flexTimedAsynch.cpp
> [[...]]
> +#define NDB_MAXTHREADS 256
> [[...]]
> diff -Nrup a/ndb/test/ndbapi/initronja.cpp b/ndb/test/ndbapi/initronja.cpp
> [[...]]
> +#define NDB_MAXTHREADS 256
> [[...]]
> diff -Nrup a/ndb/test/odbc/SQL99_test/SQL99_test.cpp
> b/ndb/test/odbc/SQL99_test/SQL99_test.cpp
> [[...]]
> +#define NDB_MAXTHREADS		24
> [[...]]

I find it somewhat confusing to see wildly varying values of 
NDB_MAXTHREADS at different places, but maybe there are convincing reasons.


Jörg

-- 
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
Office:  ([phone]     VoIP: 4464@stripped