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

Darren Duncan darren at darrenduncan.net
Sun Jan 3 21:48:13 GMT 2010


 From now on, would anyone responding to this thread on sqlite-users at sqlite.org 
please cross-post your on-topic responses to dbd-sqlite at 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-sqlite at lists.scsys.co.uk mailing list.  Adam's 
replies were also sent to sqlite-users at 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 <adamkennedybackup at gmail.com>
Reply-To: adam at ali.as
To: Darren Duncan <darren at darrenduncan.net>
CC: DBD::SQLite Mailing List <dbd-sqlite at lists.scsys.co.uk>,        General 
Discussion of SQLite Database <sqlite-users at sqlite.org>
References: <4B3EFA2A.3090507 at darrenduncan.net> 
<4B3F0480.8080609 at rogerbinns.com> <4B3F0786.50800 at 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

<snip>
 > 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:
<snip>

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 <adamkennedybackup at gmail.com>
Reply-To: adam at ali.as
To: Darren Duncan <darren at darrenduncan.net>
CC: DBD::SQLite Mailing List <dbd-sqlite at lists.scsys.co.uk>,        General 
Discussion of SQLite Database <sqlite-users at sqlite.org>
References: <4B3EFA2A.3090507 at darrenduncan.net> 
<4B3F0480.8080609 at rogerbinns.com> <4B3F0786.50800 at 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




More information about the DBD-SQLite mailing list