Hi!
On May 24, Green, Paul wrote:
> Hello,
>
> I am a software developer at Stratus Technologies and I have just spent
> a few days porting MySQL to the Stratus VOS environment. I used our
Great!
> POSIX-based "OpenVOS" environment running under VOS Release 15.2.dev.fa
> on a Stratus V200 system. This is an Intel Pentium4 Xeon processor
> running code in Big Endian format (for compatibility with our older
> PA-RISC systems).
Hmm, I know that Itanium supports big endian, but not Xeon.
Are you sure your CPU isn't Itanium ?
Just curious, the patch is still valid.
> I'm enclosing uni-diffs against revision 1.2105 (5.0.21) for the build
> issues that I had to correct. There were some other issues with missing
> features / functions in our own environment; I won't bore you with those
> details.
Ok, but does it mean that other users of Stratus VOS will be able to
build MySQL ? Or they will have to solve these "other issues" first ?
> At this point MySQL builds without errors. I haven't had a chance to run
> the tests yet. If running the tests uncovers new issues, I'll send in
> further patches.
Ok.
But even if no new issues will be found, could you send an email
confirming that ? That you had built and run MySQL, and all tests pass,
and no new patches are necessary.
For example, we may want to wait till we have complete set of patches
that are reuired for a working binary.
> I have to say that despite its enormous size, porting the MySQL source
> code to VOS was very straightforward. The issues were minor and
> resolving them was simple. Thanks for the effort that you put into
> this; I know it can't have been easy.
Good :)
> Here is a summary of what I changed.
see my questions inline in the patch.
> diff -u /subversion/mysql/cmd-line-utils/libedit/el.c.orig
> /subversion/mysql/cmd-line-utils/libedit/el.c
> --- /subversion/mysql/cmd-line-utils/libedit/el.c.orig 2006-04-26
> 14:31:03.000000000 -0400
> +++ /subversion/mysql/cmd-line-utils/libedit/el.c 2006-05-20 16:51:00.000000000
> -0400
> @@ -477,7 +477,9 @@
> sigset_t oset, nset;
>
> (void) sigemptyset(&nset);
> +#ifdef SIGWINCH
> (void) sigaddset(&nset, SIGWINCH);
> +#endif
> (void) sigprocmask(SIG_BLOCK, &nset, &oset);
to avoid many ifdef's I'd rather put
#ifndef SIGWINCH
#define SIGWINCH SIGKILL /* or some other signal that can't happen */
#endif
in, for example, cmd-line-utils/libedit/tty.h
Can you please try if it works ?
> diff -u /subversion/mysql/dbug/Makefile.in.orig /subversion/mysql/dbug/Makefile.in
> --- /subversion/mysql/dbug/Makefile.in.orig 2006-04-26 14:31:51.000000000 -0400
> +++ /subversion/mysql/dbug/Makefile.in 2006-05-24 10:36:38.000000000 -0400
> @@ -36,6 +36,7 @@
> srcdir = @srcdir@
> top_srcdir = @top_srcdir@
> VPATH = @srcdir@
> +EXEEXT = @EXEEXT@
> pkgdatadir = $(datadir)/@PACKAGE@
> pkglibdir = $(libdir)/@PACKAGE@
> pkgincludedir = $(includedir)/@PACKAGE@
> @@ -702,19 +703,19 @@
> user.ps: user.r $(NROFF_INC)
> -groff -mm user.r > $@
>
> -output1.r: factorial
> +output1.r: factorial$(EXEEXT)
> ./factorial 1 2 3 4 5 | cat > $@
Shouldn't you call the binary as ./factorial$(EXEEXT) ?
> diff -u /subversion/mysql/include/my_global.h.orig
> /subversion/mysql/include/my_global.h
> --- /subversion/mysql/include/my_global.h.orig 2006-04-26 14:30:38.000000000
> -0400
> +++ /subversion/mysql/include/my_global.h 2006-05-20 17:24:11.000000000 -0400
> @@ -1012,7 +1012,7 @@
> */
>
> /* Optimized store functions for Intel x86 */
> -#if defined(__i386__) && !defined(_WIN64)
> +#if defined(__i386__) && !defined(_WIN64) &&
> !defined(WORDS_BIGENDIAN)
I'm surprised it was the only place where it was assumed that
defined(__i386__) == !defined(WORDS_BIGENDIAN)
but well, stranger things happen :)
> #define sint2korr(A) (*((int16 *) (A)))
> #define sint3korr(A) ((int32) ((((uchar) (A)[2]) & 128) ? \
In general, changes look very reasonable, we'll probably apply them.
Thank you for your efforts!
Regards,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Kerpen, Germany
<___/ www.mysql.com
