ports/82771: Setting "BUILD_OPTIMIZED=yes" breaks ports databases/mysql40-server and .../mysql41-server on Alpha arch

Matthew X. Economou xenophon+fbsdports at irtnog.org
Wed Jun 29 11:20:22 UTC 2005

>Number:         82771
>Category:       ports
>Synopsis:       Setting "BUILD_OPTIMIZED=yes" breaks ports databases/mysql40-server and .../mysql41-server on Alpha arch
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 29 11:20:21 GMT 2005
>Originator:     Matthew X. Economou
>Release:        FreeBSD 5.4-STABLE alpha

System: FreeBSD cinep012fbweb.irtnog.org 5.4-STABLE
FreeBSD 5.4-STABLE #1: Tue Jun 21 08:37:34 EDT 2005
root at cinep012fbweb.irtnog.org:/usr/obj/usr/src/sys/GENERIC alpha

Specifically, I am running 5.4-STABLE on a DEC AlphaServer 2000
5/250 with 512 MB RAM.


Setting "BUILD_OPTIMIZED=yes" for the databases/mysql40-server and
databases/mysql41-server ports breaks MySQL on my hardware platform
(I presume no one on x86 had this problem, or at least nothing was
mentioned in a cursory web/bug DB search).

I think the problem is for integer columns with a uniqueness constraint
(e.g. primary keys), MySQL updates the index but the fails to set the
row column value (instead, it assigns the default value).  This results
in strange behavior where one can successfully insert a value, but one
cannot select/update that value, and if one attempts inserting the same
value, MySQL returns an exception because the second insert violated the
uniqueness constraint (which is likely checked through a fast (cached)
index lookup instead of a slow row lookup).

I think a compiler optimization setting that is incompatible with the
hardware platform causes this problem, perhaps due to a bug in the
compiler tool chain or in the language run-time environment.  I
recompiled MySQL without optimization, and this corrected the problem.

(I marked the severity as "Critical" because this bug completely breaks
MySQL, however I marked the priority low because this combination of
hardware and operating system is somewhat rare.)


On a computer running FreeBSD/alpha 5.4-RELEASE, while logged in as root:

cd /usr/ports/databases/mysql41-server
make install BUILD_OPTIMIZED=yes
make clean
/usr/local/etc/rc.d/mysql-server.sh start

Then, attempt to install and run a database application such as MediaWiki
or Snort (security/snort).  In the case of Snort, it will attempt to
register itself in its "sensor" table with an ID of 1, but reading the
contents of this table shows a sensor ID of 0.  Attempting to update this
value fails, and attempting to insert a row with a sensor ID of 1 fails
with a uniqueness constraint error.

I did not have time to test MySQL 5.0.


Would the port maintainer cause each port's Makefile to check for the
combination of a non-x86 platform and the BUILD_OPTIMIZED flag and to
set BROKEN or IGNORE or somehow return an error?

More information about the freebsd-ports-bugs mailing list