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 2010/1/2 Darren Duncan <dar...@darrenduncan.net>: > 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-us...@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > > _______________________________________________ > DBD-SQLite mailing list > DBD-SQLite@lists.scsys.co.uk > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite > _______________________________________________ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite