Re: Patches to correct build issues on Stratus VOS - Sergei Golubchik - com.mysql.lists.internals

8 messages in com.mysql.lists.internalsRe: Patches to correct build issues o...

From	Sent On	Attachments
Green, Paul	24 May 2006 08:02	.txt
Sergei Golubchik	26 May 2006 08:44
Green, Paul	29 May 2006 21:22
Sergei Golubchik	30 May 2006 07:12
Stewart Smith	30 May 2006 21:44
Lenz Grimmer	31 Aug 2006 13:45
Green, Paul	01 Sep 2006 04:56
Lenz Grimmer	01 Sep 2006 05:00

Subject:	Re: Patches to correct build issues on Stratus VOS
From:	Sergei Golubchik (se...@mysql.com)
Date:	05/26/2006 08:44:50 AM
List:	com.mysql.lists.internals

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