add sparc multilib and dualbuilding handling

This commit is contained in:
Dennis Gilmore 2008-03-03 17:55:21 +00:00 committed by Michal Schorm
parent 650f83934b
commit 0198dfa540

View File

@ -1,6 +1,6 @@
Name: mysql Name: mysql
Version: 5.0.45 Version: 5.0.45
Release: 9%{?dist} Release: 10%{?dist}
Summary: MySQL client programs and shared libraries Summary: MySQL client programs and shared libraries
Group: Applications/Databases Group: Applications/Databases
URL: http://www.mysql.com URL: http://www.mysql.com
@ -191,7 +191,7 @@ make check
%if %runselftest %if %runselftest
# hack to let 32- and 64-bit tests run concurrently on same build machine # hack to let 32- and 64-bit tests run concurrently on same build machine
case `uname -m` in case `uname -m` in
ppc64 | s390x | x86_64) ppc64 | s390x | x86_64 | sparc64 )
MTR_BUILD_THREAD=7 MTR_BUILD_THREAD=7
;; ;;
*) *)
@ -211,7 +211,7 @@ rm -rf $RPM_BUILD_ROOT
# multilib header hack # multilib header hack
# we only apply this to known Red Hat multilib arches, per bug #181335 # we only apply this to known Red Hat multilib arches, per bug #181335
case `uname -i` in case `uname -i` in
i386 | x86_64 | ppc | ppc64 | s390 | s390x) i386 | x86_64 | ppc | ppc64 | s390 | s390x | sparc | sparcv9 | sparc64 )
install -m 644 include/my_config.h $RPM_BUILD_ROOT/usr/include/mysql/my_config_`uname -i`.h install -m 644 include/my_config.h $RPM_BUILD_ROOT/usr/include/mysql/my_config_`uname -i`.h
install -m 644 %{SOURCE5} $RPM_BUILD_ROOT/usr/include/mysql/ install -m 644 %{SOURCE5} $RPM_BUILD_ROOT/usr/include/mysql/
;; ;;
@ -484,6 +484,10 @@ fi
%{_mandir}/man1/mysql_client_test.1* %{_mandir}/man1/mysql_client_test.1*
%changelog %changelog
* Mon Mar 03 2008 Dennis Gilmore <dennis@ausil.us> 5.0.45-10
- add sparc64 to 64 bit arches for test suite checking
- add sparc, sparcv9 and sparc64 to multilib handling
* Thu Feb 28 2008 Tom Lane <tgl@redhat.com> 5.0.45-9 * Thu Feb 28 2008 Tom Lane <tgl@redhat.com> 5.0.45-9
- Fix the stack overflow problem encountered in January. It seems the real - Fix the stack overflow problem encountered in January. It seems the real
issue is that the buildfarm machines were moved to RHEL5, which uses 64K not issue is that the buildfarm machines were moved to RHEL5, which uses 64K not