I don't believe this is a OpenBSD issue at all. This seems like an issue with MySQL. Rolling back to 3.8 might work because you are also rolling back to MySQL 4. I believe the issue is with MySQL 5. I would attempt to roll back to MySQL 4.0.27 from 3.8, run that on 3.9, see how that fares in comparison to version 5.
On Tue, May 23, 2006 at 08:33:35PM -0700, Kevin wrote: > Yeah--we tried much of the same stuff, too... different gcc > versions... going to 5.0.21 on MySQL... different compiler flags... > everything within our area of knowledge for sure. :-( > > At this point, it seems the best option is likely to roll things back > to 3.8 and (perhaps) an older version of MySQL unless anyone has any > other ideas or what-have-you. > > In case it would be useful for any OBSD devs, I can make two machines > (including an Alpha 833) available for anyone to use for > development/testing, etc. for trying to get this fixed. It seems this > affects other ports from being built (like certain php ones for > instance), so it may be a more widespread fix than just MySQL. > > There's *nothing* else on the machines right now, so there's nothing > whatsoever to be damaged. > > Thanks all, > Kevin > > > > On 5/23/06, Brad <[EMAIL PROTECTED]> wrote: > >Actually that was me trying to get it working with gcc 2.95, that patch > >was necessary to allow MySQL 5.0.18 to at least compile but as you had > >noticed it did not actually run properly. I updated to MySQL 5.0.21 which > >was commited to the 3.9 -stable branch and noticed that the patch no > >longer seems to be required to allow it to compile, though ending with > >the same result of MySQL not working. I was also playing around with > >gcc 3.3.6 on your system, but nothing I did resulted in a working > >binary. :( > > > > > >On Tue, May 23, 2006 at 11:22:49AM -0700, Kevin wrote: > >> Hello all, > >> > >> With a patch (see below) kindly provided by brad@ we were able to > >> get MySQL 5.x to build from ports on an Alphaserver and not bail with > >> internal gcc compiler errors; however, when a: > >> > >> # pkg_add mysql-server-5.0.xx.tgz > >> > >> is run MySQL reliably core dumps every time as it's nearing completion > >> of the package installation with this error: > >> > >> ############### > >> mysql-server-5.0.18: complete > >> pid 16934 (mysqld): unaligned access: va=0x1205602a7 pc=0x120367bb4 > >> ra=0x120367d0c op=ldl > >> Bus error (core dumped) > >> ############### > >> > >> > >> At this point, it's checkmate, as creating the stock tables manually > >> (and/or starting MySQL manually) doesn't work and results in the same > >> core dump. > >> > >> Anyone else have any thoughts? > >> > >> > >> Here's Brad's patch: > >> ####################### > >> gcc-patch-sql-Makefile_in > >> ####################### > >> $OpenBSD$ > >> --- sql/Makefile.in.orig Fri May 12 16:00:08 2006 > >> +++ sql/Makefile.in Fri May 12 16:00:46 2006 > >> @@ -1261,6 +1261,9 @@ lex_hash.h: gen_lex_hash$(EXEEXT) > >> udf_example.so: udf_example.cc > >> $(CXXCOMPILE) -shared -o $@ $< > >> > >> +sql_table.o: sql_table.cc > >> + $(CXXCOMPILE) -O0 -c -o $@ $< > >> + > >> # Don't update the files from bitkeeper > >> %::SCCS/s.% > >> # Tell versions [3.59,3.63) of GNU make to not export all variables. > >> > >> > >> As always: thanks, especially to Brad for spending some time trying to > >> get things going for me. > >> Kevin > >> > >> > >> > >> > >> -- > >> http://www.ebiinc.com : > >> Background Screening from EBI > >> National & International Background Checks
