Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
From now on, would anyone responding to this thread on sqlite-users@sqlite.org please cross-post your on-topic responses to dbd-sql...@lists.scsys.co.uk as I am? I moderate the dbd-sqlite list and will let your postings through even if you aren't subscribed to it. This is to help save me some manual forwarding work. Thank you. Adam Kennedy had yesterday posted replies to Roger's first reply which I effectively forwarded to the dbd-sql...@lists.scsys.co.uk mailing list. Adam's replies were also sent to sqlite-users@sqlite.org but the list moderators didn't yet let them through to the list so I'm forwarding a compilation of them for the latter's benefit. -- Darren Duncan 1 of 2: Original Message Subject: Re: [DBD-SQLite] Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10 Date: Sun, 3 Jan 2010 14:55:39 +1100 From: Adam Kennedy <adamkennedybac...@gmail.com> Reply-To: a...@ali.as To: Darren Duncan <dar...@darrenduncan.net> CC: DBD::SQLite Mailing List <dbd-sql...@lists.scsys.co.uk>,General Discussion of SQLite Database <sqlite-users@sqlite.org> References: <4b3efa2a.3090...@darrenduncan.net> <4b3f0480.8080...@rogerbinns.com> <4b3f0786.50...@darrenduncan.net> Thanks for the comments on the build flags, we will investigate. The threadsafe disabling may be a result of DBD::SQLite being itself compiled on a Perl that has threading compiled out (which adds about 10-20% overall speed and is used in certain situations). Adam K DBD::SQLite Release Manager > Roger Binns wrote [to sqlite-us...@sqlite.org]: >> >> Darren Duncan wrote: >>> >>> I would like to bring an apparent SQLite bug to the attention of the >>> SQLite core developers as a ticket, where build fails on sun4-solaris-64int >>> 2.10 >> >> You'll find this is not a bug in SQLite. >> >>> cc: Fatal error in /opt/sunstudio12.1/prod/bin/cg >>> cc: Status 139 >>> *** Error code 139 >> >> That is the compiler crashing (signal 11, SIGSEGV). This sort of thing >> usually turns out to be an optimiser bug and likely won't happen if you >> disable optimisation, or compile the files individually rather than >> using the amalgamation. Alternatively use a working compiler like gcc. >> >> Incidentally three of your defines are dodgy: 2 of 2: Original Message Subject: Re: [DBD-SQLite] Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10 Date: Sun, 3 Jan 2010 15:47:22 +1100 From: Adam Kennedy <adamkennedybac...@gmail.com> Reply-To: a...@ali.as To: Darren Duncan <dar...@darrenduncan.net> CC: DBD::SQLite Mailing List <dbd-sql...@lists.scsys.co.uk>,General Discussion of SQLite Database <sqlite-users@sqlite.org> References: <4b3efa2a.3090...@darrenduncan.net> <4b3f0480.8080...@rogerbinns.com> <4b3f0786.50...@darrenduncan.net> The build code we're using is run across all operating systems. You can see the actual build script here. [ http://svn.ali.as/cpan/trunk/DBD-SQLite/Makefile.PL ] Unfortunately, we neither have the ability to run configure (as we don't have reliable access to /bin/sh or any of the other stuff it needs) or the ability to use a pregenerated static configuration across all platforms. But your other comments are welcome. I've removed the useless pointer size flag, and commented out the core flag until we can determine why it was there in the first place (there's a new team looking after DBD::SQLite since about March last year, and some stuff is definitely grandfathered in from long ago). Adam K >> The other flags seem to be guessed. There is no need to tell a 64 bit >> system that file offets are 64 bits. The only 'have' is HAVE_USLEEP but >> the system likely has LOCALTIME_R and GMTIME_R too as well as several >> other header files. >> >> If you do not want to build SQLite using its build system then the >> approach I take is to run SQLite's configure, grab the DEFS = line out >> of the resulting Makefile and generate a .h file with the relevant -D >> turned into #defines. If you define _HAVE_SQLITE_CONFIG_H then SQLite >> will #include any config.h so you can dump your #defines in there. >> >> Roger ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
Darren Duncan wrote: > I would like to bring an apparent SQLite bug to the attention of the SQLite > core > developers as a ticket, where build fails on sun4-solaris-64int 2.10. > > This problem was reported to the DBD::SQLite (Perl binding) developers as an > automatically generated smoke tester ticket which can be seen here for all > the > details, but I have copied the most central portion into this email below the > dashed line: > > http://www.nntp.perl.org/group/perl.cpan.testers/2009/12/msg6529201.html > > Note that the DBD::SQLite version that was tested bundles SQLite 3.6.20, so > there is a chance that the latest 3.6.21 fixes it; if you think it necessary > I > can try asking the tester to try with the newer version. > > Thank you. > > -- Darren Duncan I get the same warnings as Darren with Sun Studio - the Sun compiler tends to be more fussy than gcc. But my build does succeed. This is version 3.6.19 I assume. The output below is from a Sun Ultra 27 (Xeon processor), but I've built sqlite on Solaris 10 SPARC, from both the first version (02/2005) and the latest Solaris 10 update 7 (late 2009). /opt/sunstudio12.1/bin/cc "-DPACKAGE_NAME=\"sqlite\"" "-DPACKAGE_TARNAME=\"sqlite\"" "-DPACKAGE_VERSION=\"3.6.19\"" "-DPACKAGE_STRING=\"sqlite 3.6.19\"" "-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; "-DPACKAGE=\"sqlite\"" "-DVERSION=\"3.6.19\"" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_READLINE=1 -I. -I. -I /export/home/drkirkby/sage-4.3/local/include -DSQLITE_THREADSAFE=1 -m64 -g -O2 -c sqlite3.c -KPIC -DPIC -o .libs/sqlite3.o "sqlite3.c", line 19207: warning: integer overflow detected: op "<<" "sqlite3.c", line 19224: warning: integer overflow detected: op "<<" "sqlite3.c", line 33277: warning: statement not reached "sqlite3.c", line 70955: warning: integer overflow detected: op "<<" /opt/sunstudio12.1/bin/cc "-DPACKAGE_NAME=\"sqlite\"" "-DPACKAGE_TARNAME=\"sqlite\"" "-DPACKAGE_VERSION=\"3.6.19\"" "-DPACKAGE_STRING=\"sqlite 3.6.19\"" "-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"; "-DPACKAGE=\"sqlite\"" "-DVERSION=\"3.6.19\"" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_READLINE=1 -I. -I. -I /export/home/drkirkby/sage-4.3/local/include -DSQLITE_THREADSAFE=1 -m64 -g -O2 -c sqlite3.c -o sqlite3.o >/dev/null 2>&1 I do not know how much access sqlite developers have to Solaris machines, but if they need access to a SPARC, I can get a serious developer access to a T5240 via the University of Washington. Just drop me an email, with your preferred user name and state your role in sqlite development. Dave ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Duncan wrote: > Roger, thank you for this quick response, and for your tips. So from the > looks > of what you're saying, the problem is actually related to something that the > DBD::SQLite build process is doing inadequately, so now I suspect the ball > will > go back there to be dealt with. The immediate cause of the compilation failure is a buggy compiler and nobody's fault except Sun. Separately from that various defines are not as appropriate as they could be which is probably a DBD:SQLite build process issue. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks/iGoACgkQmOOfHg372QQODQCeNW7rwVRKY5mFNhq4fnw3dB5M yOIAoMl4EavG/ZmF7qZrF+NKNdMCU0J1 =l3rA -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
Op 2-jan-2010, om 9:32 heeft Roger Binns het volgende geschreven: > Darren Duncan wrote: >> I would like to bring an apparent SQLite bug to the attention of >> the SQLite core >> developers as a ticket, where build fails on sun4-solaris-64int 2.10 > > You'll find this is not a bug in SQLite. > >> cc: Fatal error in /opt/sunstudio12.1/prod/bin/cg >> cc: Status 139 >> *** Error code 139 > > That is the compiler crashing (signal 11, SIGSEGV). This sort of > thing > usually turns out to be an optimiser bug and likely won't happen if > you > disable optimisation, or compile the files individually rather than > using the amalgamation. Alternatively use a working compiler like > gcc. > > Incidentally three of your defines are dodgy: > > -DSQLITE_CORE > > There is never any need to specify this - all that stuff is handled > internally. > > -DSQLITE_PTR_SZ=4 > > That name is not used anywhere in the SQLite source I could find. > Even > if it was, implying 4 byte pointers on a 64 bit machine seems > dangerous. > > -DTHREADSAFE=0 > > Really? What is wrong (and less likely to cause the unwary grief) > than > the default of 1? > > The other flags seem to be guessed. There is no need to tell a 64 bit > system that file offets are 64 bits. The only 'have' is > HAVE_USLEEP but > the system likely has LOCALTIME_R and GMTIME_R too as well as several > other header files. > > If you do not want to build SQLite using its build system then the > approach I take is to run SQLite's configure, grab the DEFS = line out > of the resulting Makefile and generate a .h file with the relevant -D > turned into #defines. If you define _HAVE_SQLITE_CONFIG_H then SQLite > will #include any config.h so you can dump your #defines in there. > > Roger Hello, just one remark with regards to the thread-safe option: the default setting has changed in the configure script of version 3.6.21. It has now become 0 and the --enable-theadsafe argument is required to configure for threadsafety (strongly recommended for shared cache mode). Regads, Edzard Pasma ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
Roger, thank you for this quick response, and for your tips. So from the looks of what you're saying, the problem is actually related to something that the DBD::SQLite build process is doing inadequately, so now I suspect the ball will go back there to be dealt with. Thank you. -- Darren Duncan Roger Binns wrote [to sqlite-us...@sqlite.org]: > Darren Duncan wrote: >> I would like to bring an apparent SQLite bug to the attention of the SQLite >> core >> developers as a ticket, where build fails on sun4-solaris-64int 2.10 > > You'll find this is not a bug in SQLite. > >> cc: Fatal error in /opt/sunstudio12.1/prod/bin/cg >> cc: Status 139 >> *** Error code 139 > > That is the compiler crashing (signal 11, SIGSEGV). This sort of thing > usually turns out to be an optimiser bug and likely won't happen if you > disable optimisation, or compile the files individually rather than > using the amalgamation. Alternatively use a working compiler like gcc. > > Incidentally three of your defines are dodgy: > > -DSQLITE_CORE > > There is never any need to specify this - all that stuff is handled > internally. > > -DSQLITE_PTR_SZ=4 > > That name is not used anywhere in the SQLite source I could find. Even > if it was, implying 4 byte pointers on a 64 bit machine seems dangerous. > > -DTHREADSAFE=0 > > Really? What is wrong (and less likely to cause the unwary grief) than > the default of 1? > > The other flags seem to be guessed. There is no need to tell a 64 bit > system that file offets are 64 bits. The only 'have' is HAVE_USLEEP but > the system likely has LOCALTIME_R and GMTIME_R too as well as several > other header files. > > If you do not want to build SQLite using its build system then the > approach I take is to run SQLite's configure, grab the DEFS = line out > of the resulting Makefile and generate a .h file with the relevant -D > turned into #defines. If you define _HAVE_SQLITE_CONFIG_H then SQLite > will #include any config.h so you can dump your #defines in there. > > Roger > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
Darren Duncan wrote: > I would like to bring an apparent SQLite bug to the attention of the SQLite > core > developers as a ticket, where build fails on sun4-solaris-64int 2.10 You'll find this is not a bug in SQLite. > cc: Fatal error in /opt/sunstudio12.1/prod/bin/cg > cc: Status 139 > *** Error code 139 That is the compiler crashing (signal 11, SIGSEGV). This sort of thing usually turns out to be an optimiser bug and likely won't happen if you disable optimisation, or compile the files individually rather than using the amalgamation. Alternatively use a working compiler like gcc. Incidentally three of your defines are dodgy: -DSQLITE_CORE There is never any need to specify this - all that stuff is handled internally. -DSQLITE_PTR_SZ=4 That name is not used anywhere in the SQLite source I could find. Even if it was, implying 4 byte pointers on a 64 bit machine seems dangerous. -DTHREADSAFE=0 Really? What is wrong (and less likely to cause the unwary grief) than the default of 1? The other flags seem to be guessed. There is no need to tell a 64 bit system that file offets are 64 bits. The only 'have' is HAVE_USLEEP but the system likely has LOCALTIME_R and GMTIME_R too as well as several other header files. If you do not want to build SQLite using its build system then the approach I take is to run SQLite's configure, grab the DEFS = line out of the resulting Makefile and generate a .h file with the relevant -D turned into #defines. If you define _HAVE_SQLITE_CONFIG_H then SQLite will #include any config.h so you can dump your #defines in there. Roger ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10
I would like to bring an apparent SQLite bug to the attention of the SQLite core developers as a ticket, where build fails on sun4-solaris-64int 2.10. This problem was reported to the DBD::SQLite (Perl binding) developers as an automatically generated smoke tester ticket which can be seen here for all the details, but I have copied the most central portion into this email below the dashed line: http://www.nntp.perl.org/group/perl.cpan.testers/2009/12/msg6529201.html Note that the DBD::SQLite version that was tested bundles SQLite 3.6.20, so there is a chance that the latest 3.6.21 fixes it; if you think it necessary I can try asking the tester to try with the newer version. Thank you. -- Darren Duncan -- Output from '/usr/ccs/bin/make': cc -c -I. -I/usr/perl5/site_perl/5.8.4/sun4-solaris-64int/auto/DBI -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -O2 -DVERSION=\"1.27\" -DXS_VERSION=\"1.27\" -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE" -DSQLITE_CORE -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_COLUMN_METADATA -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 -DTHREADSAFE=0 sqlite3.c "sqlite3.c", line 19219: warning: integer overflow detected: op "<<" "sqlite3.c", line 19236: warning: integer overflow detected: op "<<" "sqlite3.c", line 33316: warning: statement not reached "sqlite3.c", line 71102: warning: integer overflow detected: op "<<" cc: Fatal error in /opt/sunstudio12.1/prod/bin/cg cc: Status 139 *** Error code 139 make: Fatal error: Command failed for target `sqlite3.o' ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
