[DBD-SQLite] Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10

[Adam Kennedy]

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 <darren at 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-users at 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 at sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
> _______________________________________________
> DBD-SQLite mailing list
> DBD-SQLite at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
>