Re: More info on MySQL 5.0 on OpenBSD 3.9 Alpha
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.origFri 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
Re: More info on MySQL 5.0 on OpenBSD 3.9 Alpha
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.origFri 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
Re: More info on MySQL 5.0 on OpenBSD 3.9 Alpha
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.origFri 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
