MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:Paul Green Date:May 30 2006 4:22am
Subject:RE: Patches to correct build issues on Stratus VOS
View as plain text  
Sergei Golubchik [mailto:serg@stripped] wrote:
> On May 24, Green, Paul wrote
[snip]
>> 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.

Quite sure!  I work for the vendor... ;-).  We modified our compilers,
and we modified gcc/gdb, etc., so that the compilers do the necessary
byte-swapping when data is loaded or stored into memory.  As a result,
our customers can port big-endian based source code from our older
PA-RISC systems without having to convert it to little-endian (or
endian-neutral) form.  As you might expect, we give up some performance
doing the byte-swapping, but we saved ourselves and our customers a
tremendous amount of work.  I only wish that Intel had added some x86
instructions to do the byte-swaps as a part of the load or store
instructions; I'm sure they could have made them zero-cost that way.  We
aren't the only big-endian x86 implementation; I forget who the other
vendor is; but we gave them our gcc mods.
 
>> 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 ?

My intention is to correct all of the issues that prevent a stock MySQL
source code distribution file from building on Stratus VOS.  I hope to
have all of the Stratus VOS changes installed into the next major
release(s) of VOS, which will be VOS Release 15.3 and 16.0.  These
releases will appear in the next 6-9 months.  We are working on these
two releases in parallel right now.  Customers will either need to wait
for one of these releases, or they will need to apply the same local
fixes that I have made.  If there is sufficient interest in MySQL from
our customers, I will probably distribute a version of MySQL for VOS
that already has the necessary workarounds in place.  That is, I'll do
this if the MySQL license allows it.  I admit to not having read it
closely enough to see if that will be ok with you.  I would certainly
verify the licensing issues before uploading it to our anonymous ftp
site.

I wouldn't dream of submitting these patches back to you; they represent
defects in VOS, and I would hate to pollute the MySQL source code base
with stuff to work around our errors and omissions.  Some of these
issues represent bugs on our part, and some represent POSIX-2001
features that we lack.  We have a fairly complete POSIX-96
implementation, but we do not have many of the POSIX-2001 new features.
At the moment, it doesn't appear that it will be all that hard to simply
change our implementation to agree with your needs.  To give you a
flavor of the issues, here is a fairly complete list:

* MySQL assumes that stdio.h contains the P_tmpdir macro. We are missing
it. Trivial fix.
* I built MySQL in "SYSV" compatibility mode. In this mode, we don't
have mkstemp. We should have it tho. Trivial fix.
* Our copy of sys/poll.h is missing the prototype for the poll()
function. Trivial fix.
* MySQL assumes that libm.a exists. Our linker doesn't use library files
for the standard C/POSIX runtime routines. We don't have libm.a.  (We
implement library files, we just don't use them for the standard
routines, due to historical technical decisions).  I supplied an empty
one to satisfy MySQL. Trivial fix.
* We don't implement Unix Domain Sockets, and don't have socketpair()
and sys/un.h.  I will either implement these directly, or implement a
version that maps them into loopback sockets. Not so trivial...
* We don't have a sys/resource.h header.  I was able to supply an empty
one. Trivial fix.
* We don't have setregid or setreuid.  We have the other flavors...I
haven't had a chance to research how to work around this issue yet.
* Our declaration of bcmp doesn't have "const" on its arguments. This
generated warnings when I built MySQL. Trivial fix.
* We don't have msync or the MS_SYNC macro.  Something else I'll need to
implement. Difficulty unclear.
* We don't have chroot().  Doesn't appear that we really need it, so I
just added our system to the list of other systems that don't implement
it (in the patch I sent you).
* We don't have regcomp/regexec/regfree or regex.h.  Somehow, we have
ported a ton of open-source software without any of it using these
functions. I'll go find a copy of it with an appropriate license and
port it to our system. Pretty simple fix.

I know a software engineer working for one of our customers who ported
MySQL to VOS and simply worked around all of these issues himself.  I
would rather just fix VOS so that we implement these things.  Sometimes
when I ported open-source products, I ship a small library of headers
and functions right with the open-source package; these files make up
for missing functions and headers in VOS.  I may do this for MySQL too,
but my preference would be to simply fix the next release.  

>> 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 ?

Sure, no problem.

>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 required for a working binary.

That makes sense.  I will make a point to send you another set of
patches once all the tests work.  That way, there will be a record of
all the patches needed to make it work on VOS.  If you would prefer to
wait and review the patches at that time, that's fine by me.
 
[snip]

> 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 ?

Sure, no problem.  I backed out all of the SIGWINCH changes, and then
added your suggested macro to tty.h.  I am happy to report that MySQL
builds without errors, so it looks like this is a perfectly acceptable
alternative solution.

>> 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 @@
[snip]
>> +EXEEXT = @EXEEXT@
[snip]
>> -output1.r:      factorial
>> +output1.r:      factorial$(EXEEXT)
>>               ./factorial 1 2 3 4 5 | cat > $@
>
>Shouldn't you call the binary as ./factorial$(EXEEXT) ?

We have pretty much the same rules as MS-DOS or Windows (by co-incidence
not by design). A VOS executable file is named "foo.pm" but the command
processor does not require you to specify the ".pm" suffix.  You may
specify it, but if you don't, it is automatically added for you.  Our
port of bash deals with this.  So "./factorial" is fine, and
"./factorial.pm" would also work.  By convention, we prefer the former
over the latter.

>> 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 @@
[snip]
>> -#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 :)

It is the only one I have found thus far.  A number of open-source
packages make this assumption...OpenSSL for example.

>In general, changes look very reasonable, we'll probably apply them.
>Thank you for your efforts!
>
>Regards,
>Sergei

And I thank you for your excellent questions and for taking the time to
read and respond to my letter!

Thanks
PG
--
Paul Green, Sr. Technical Consultant
Stratus Technologies, Inc., Maynard, MA 01754 USA
Tel: +1 (978) 461-7557, Fax: +1 (978) 461-3610, AIM: PaulGreen
Thread
Patches to correct build issues on Stratus VOSPaul Green24 May
  • Re: Patches to correct build issues on Stratus VOSSergei Golubchik26 May
RE: Patches to correct build issues on Stratus VOSPaul Green30 May
  • Re: Patches to correct build issues on Stratus VOSSergei Golubchik30 May
  • RE: Patches to correct build issues on Stratus VOSStewart Smith31 May
  • RE: Patches to correct build issues on Stratus VOSLenz Grimmer31 Aug
RE: Patches to correct build issues on Stratus VOSPaul Green1 Sep
  • RE: Patches to correct build issues on Stratus VOSLenz Grimmer1 Sep