Remove the ancient and dead raid code. By now, even the server side
has been removed.

Remove unused source code and associated paraphernalia.

Remove Windows related files which aren't used anymore.

Remove unused variables.

Remove code that has been disabled for a long time.

Bug#52261: 64 bit atomic operations do not work on Solaris i386
           gcc in debug compilation

One of the various problems was that the source operand to
CMPXCHG8b was marked as a input/output operand, causing GCC
to use the EBX register as the destination register for the
CMPXCHG8b instruction. This could lead to crashes as the EBX
register is also implicitly used by the instruction, causing
the value to be potentially garbaged and a protection fault
once the value is used to access a position in memory.

Another problem was the lack of proper clobbers for the atomic
operations and, also, a discrepancy between the implementations
for the Compare and Set operation. The specific problems are
described and fixed by Kristian Nielsen patches:

Patch: 1

Fix bugs in my_atomic_cas*(val,cmp,new) that *cmp is accessed
after CAS succeds.

In the gcc builtin implementation, problem was that *cmp was
read again after atomic CAS to check if old *val == *cmp;
this fails if CAS is successful and another thread modifies
*cmp in-between.

In the x86-gcc implementation, problem was that *cmp was set
also in the case of successful CAS; this means there is a
window where it can clobber a value written by another thread
after successful CAS.

Patch 2:

Add a GCC asm "memory" clobber to primitives that imply a
memory barrier.

This signifies to GCC that any potentially aliased memory
must be flushed before the operation, and re-read after the
operation, so that read or modification in other threads of
such memory values will work as intended.

In effect, it makes these primitives work as memory barriers
for the compiler as well as the CPU. This is better and more
correct than adding "volatile" to variables.

This bug is a design flaw of the fix for the bug#33546. It assumed that an
item can be used only in one comparison context, but actually it isn't the
case. Item_cache_datetime is used to store result for MIX/MAX aggregate
functions. Because Arg_comparator always compares datetime values as INTs when
possible the Item_cache_datetime most time caches only INT value. But
since all datetime values has STRING result type MIN/MAX functions are asked
for a STRING value when the result is being sent to a client. The
Item_cache_datetime was designed to avoid conversions and get INT/STRING
values from an underlying item, but at the moment the values is asked
underlying item doesn't hold it anymore thus wrong result is returned.
Beside that MIN/MAX aggregate functions was wrongly initializing cached result
and this led to a wrong result.

The Item::has_compatible_context helper function is added. It checks whether
this and given items has the same comparison context or can be compared as
DATETIME values by Arg_comparator. The equality propagation optimization is
adjusted to take into account that items which being compared as DATETIME
can have different comparison contexts.
The Item_cache_datetime now converts cached INT value to a correct STRING
DATETIME value by means of number_to_datetime & my_TIME_to_str functions.
The Arg_comparator::set_cmp_context_for_datetime helper function is added. 
It sets comparison context of items being compared as DATETIMEs to INT if
items will be compared as longlong.
The Item_sum_hybrid::setup function now correctly initializes its result
value.
In order to avoid unnecessary conversions Item_sum_hybrid now states that it
can provide correct longlong value if the item being aggregated can do it
too.

Put '-features=no%except' back into Solaris/x86 CXXFLAGS.

Conflicts:
  - scripts/CMakeLists.txt

This assert checks that the server does not try to send OK to the
client if there has been some error during processing. This is done
to make sure that the error is in fact sent to the client.

The problem was that view errors during processing of WHERE conditions
in UPDATE statements where not detected by the update code. It therefore
tried to send OK to the client, triggering the assert.
The bug was only noticeable in debug builds.

This patch fixes the problem by making sure that the update code
checks for errors during condition processing and acts accordingly.

Post-merge fix: remove leftovers from safemalloc removal.

applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug

applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug

Bug#47139: Test "merge" crashes in "embedded" run

Backport patch for Bug#47139

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

of the "embedded" server

Problem: mysqltest_embedded failed to load ha_innodb_plugin library
on some platforms (due to some unresolved references).

Fix: on FreeBSD use -export-dynamic flag building mysqltest_embedded.
That allows to use its global symbols to resolve references in the
dynamically loaded plugin library.

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)

Backporting the fix from myql-next-mr (5.6) to mysql-trunk (5.5)

This fix is for cleanup, to resolve a remaining code review item.
Backport from mysql-next-mr (5.6) to mysql-trunk (5.5).