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

[Darren Duncan]

Roger Binns wrote [on Sun, 03 Jan 2010 09:56:46 -0800]:
> Adam Kennedy wrote:
>> 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.
> 
> Well, you already pre-generate -DHAVE_USLEEP which doesn't exist on Windows
> or older Unixen!  Your only workaround is to read/run the real configure to
> see what kind of stuff it generates and then write your own tests to
> generate the same flags.
> 
> GMTIME_R/LOCALTIME_R will affect performance if doing date/time code - not
> having them means SQLite internally uses a mutex around calls to
> gmtime/localtime which still leaves you vulnerable to bogus data if any
> other non-SQLite thread in the program calls those functions.
> 
> The other flags mainly cover header file presence and you'll generally get
> away without defines for them (unistd.h likely has everything anyway).  The
> only likely gotcha is if you have extension loading enabled in which case
> SQLite needs to know which header contains dlopen and friends.

In response to the above message, following is Adam Kennedy's reply of 
yesterday, which I am forwarding to the sqlite-users list.

Anyone on sqlite-users who wants to respond on this thread, please cross-post 
to 
dbd-sql...@lists.scsys.co.uk (which I moderate) and I will let it in.  Anyone 
on 
dbd-sqlite only that is interested in such issues should also join sqlite-users 
so they can post to it directly.

-- Darren Duncan

---- Original Message --------
Subject: Re: [Fwd: Re: [sqlite] [DBD-SQLite] Re: SQLite bug ticket - build 
fails on sun4-solaris-64int 2.10]
Date: Mon, 4 Jan 2010 10:40:21 +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>
References: <4b41113f.1060...@darrenduncan.net>

(Darren can you bump this onto the SQLite list? Thanks)

The HAVE_USLEEP flag is provided by the following.

if ( $Config{d_usleep} || $Config{osname} =~ m/linux/ ) {
push @CC_DEFINE, '-DHAVE_USLEEP=1';
}

The %Config hash exposes the internal flags and settings that the
underlying Perl language was originally compiled with.

The $Config{d_usleep} flag should be true if the original Perl
./Configure run detected it.

I can confirm that when I build on Windows we don't use HAVE_USLEEP

Adam K
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

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

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adam Kennedy wrote:
> 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.

Well, you already pre-generate -DHAVE_USLEEP which doesn't exist on Windows
or older Unixen!  Your only workaround is to read/run the real configure to
see what kind of stuff it generates and then write your own tests to
generate the same flags.

GMTIME_R/LOCALTIME_R will affect performance if doing date/time code - not
having them means SQLite internally uses a mutex around calls to
gmtime/localtime which still leaves you vulnerable to bogus data if any
other non-SQLite thread in the program calls those functions.

The other flags mainly cover header file presence and you'll generally get
away without defines for them (unistd.h likely has everything anyway).  The
only likely gotcha is if you have extension loading enabled in which case
SQLite needs to know which header contains dlopen and friends.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktA2l4ACgkQmOOfHg372QTpYACfYyh1PPCLcFN58xesZw1JknL9
AxkAoKTvDHoniKKJe1EoYeeruvbH+5Sr
=GEli
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

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

[Adam Kennedy]

Apologies, that should be...

http://svn.ali.as/cpan/trunk/DBD-SQLite/Makefile.PL

2010/1/3 Adam Kennedy :
> The build code we're using is run across all operating systems.
>
> You can see the actual build script here.
>
> http://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] [DBD-SQLite] Re: SQLite bug ticket - build fails on sun4-solaris-64int 2.10

[Adam Kennedy]

The build code we're using is run across all operating systems.

You can see the actual build script here.

http://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] [DBD-SQLite] Re: 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 :
> 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
>>
>
>
> ___
> DBD-SQLite mailing list
> dbd-sql...@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users