Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
Your alternative to sqlite3_mutex_try() doesn't link on NT/2000/XP/Vista
because you still
have TryEnterCriticalSection there instead of getting the pointer to it
dynamically as Nicolas
suggested. So the current mutex_w32.c 1.4 does compile but won't link either.
http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/mutex_w32.c=1.3=1.4
To link it you have to add
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif _WIN32_WINNT
somewhere, I added it after the include guard in the amalgamation sqlite3.c of
3.5.0 alpha,
which I have done now to remove a link error in my code and it works. Hope drh
adds it in
the CVS.
I second that Win9X support should be dropped, it's as pointless as supporting
MS-DOS now.
It should have been dropped when sqlite3 was released.
-- sword
On Wed, 05 Sep 2007 10:20:37 +0200
Ralf Junker <[EMAIL PROTECTED]> wrote:
>
> >Isn't it time to drop the Win9X support from the default build?
>
> I do not believe that just because Win9x is missing a single required call
> justifies dropping support for it altogether!
>
> >I'm thinking that any optimization should be enabled for the majority of
> >users. Or if it's not really an optimization, why keeping it in the code
> >then?
>
> If possible, please keep the optimization.
>
> >An alternative is to call this function when available using
> >"GetProcAddress" (this is the case for a lot of other modern calls that
> >cannot be done right now).
>
> I second this alternative.
>
> According to http://msdn2.microsoft.com/en-us/library/ms686857.aspx,
> TryEnterCriticalSection() is available on all Windows NT sytems. Therefore an
> option to "GetProcAddress()" is checking for such OSes. The isNT() routine is
> already part of os_win.c and is used there frequently:
>
> static int isNT(void){
> if( sqlite3_os_type==0 ){
> OSVERSIONINFO sInfo;
> sInfo.dwOSVersionInfoSize = sizeof(sInfo);
> GetVersionEx();
> sqlite3_os_type = sInfo.dwPlatformId==VER_PLATFORM_WIN32_NT ? 2 : 1;
> }
> return sqlite3_os_type==2;
> }
>
>
> sqlite3_mutex_try() would then extend to something like this (untested!):
>
> int sqlite3_mutex_try(sqlite3_mutex *p){
> int rc;
> assert( p );
> assert( p->id==SQLITE_MUTEX_RECURSIVE || sqlite3_mutex_notheld(p) );
> if( isNT() && TryEnterCriticalSection(>mutex) ){
> p->owner = GetCurrentThreadId();
> p->nRef++;
> rc = SQLITE_OK;
> }else{
> rc = SQLITE_BUSY;
> }
> return rc;
> }
>
> Ralf
>
>
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
>Isn't it time to drop the Win9X support from the default build?
I do not believe that just because Win9x is missing a single required call
justifies dropping support for it altogether!
>I'm thinking that any optimization should be enabled for the majority of
>users. Or if it's not really an optimization, why keeping it in the code then?
If possible, please keep the optimization.
>An alternative is to call this function when available using "GetProcAddress"
>(this is the case for a lot of other modern calls that cannot be done right
>now).
I second this alternative.
According to http://msdn2.microsoft.com/en-us/library/ms686857.aspx,
TryEnterCriticalSection() is available on all Windows NT sytems. Therefore an
option to "GetProcAddress()" is checking for such OSes. The isNT() routine is
already part of os_win.c and is used there frequently:
static int isNT(void){
if( sqlite3_os_type==0 ){
OSVERSIONINFO sInfo;
sInfo.dwOSVersionInfoSize = sizeof(sInfo);
GetVersionEx();
sqlite3_os_type = sInfo.dwPlatformId==VER_PLATFORM_WIN32_NT ? 2 : 1;
}
return sqlite3_os_type==2;
}
sqlite3_mutex_try() would then extend to something like this (untested!):
int sqlite3_mutex_try(sqlite3_mutex *p){
int rc;
assert( p );
assert( p->id==SQLITE_MUTEX_RECURSIVE || sqlite3_mutex_notheld(p) );
if( isNT() && TryEnterCriticalSection(>mutex) ){
p->owner = GetCurrentThreadId();
p->nRef++;
rc = SQLITE_OK;
}else{
rc = SQLITE_BUSY;
}
return rc;
}
Ralf
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
[EMAIL PROTECTED] wrote: - Original Message From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Tuesday, September 4, 2007 3:32:38 PM Subject: Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error =?ISO-8859-1?Q?Daniel_=D6nnerby?= <[EMAIL PROTECTED]> wrote: Hi all! Tried upgrading to the 3.5.0 alpha from 3.4.2 using VS 2005 on XP. I downloaded the ZIP with preprocessed C code. Compiling SQLite to a .lib was no problem, but when linking it to an ..exe I got the following: sqlite.lib(mutex_w32.obj) : error LNK2019: unresolved external symbol _TryEnterCriticalSection referenced in function _sqlite3_mutex_try I made some attempt to fix it checking all kind of possible errors on my side (defines, compiler/linker settings etc) without any luck. Anyone got the same error? BTW. SQLite 3.4.2 works just fine. This is not a big deal for me to solve, just thought I share with the development team. http://www.sqlite.org/cvstrac/chngview?cn=4399 -- D. Richard Hipp [EMAIL PROTECTED] Isn't it time to drop the Win9X support from the default build? I'm thinking that any optimization should be enabled for the majority of users. Or if it's not really an optimization, why keeping it in the code then? If some people still need to compile for legacy OSes, they can always grab the source and compile without those optimizations. An alternative is to call this function when available using "GetProcAddress" (this is the case for a lot of other modern calls that cannot be done right now). I agree, or at least make one OS-layer for winnt and one for win9x. I also found out what I was doing wrong. The _WIN32_WINNT should be set like: _WIN32_WINNT=0x0400 (or something higher) Just my 2c Nicolas - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
- Original Message > From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > To: sqlite-users@sqlite.org > Sent: Tuesday, September 4, 2007 3:32:38 PM > Subject: Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error > > > =?ISO-8859-1?Q?Daniel_=D6nnerby?= <[EMAIL PROTECTED]> wrote: > > Hi all! > > > > Tried upgrading to the 3.5.0 alpha from 3.4.2 using VS 2005 on XP. I > > downloaded the ZIP with preprocessed C code. > > Compiling SQLite to a .lib was no problem, but when linking it to an > > ..exe I got the following: > > sqlite.lib(mutex_w32.obj) : error LNK2019: unresolved external symbol > > _TryEnterCriticalSection referenced in function _sqlite3_mutex_try > > > > I made some attempt to fix it checking all kind of possible errors on my > > side (defines, compiler/linker settings etc) without any luck. > > Anyone got the same error? > > BTW. SQLite 3.4.2 works just fine. > > > > This is not a big deal for me to solve, just thought I share with the > > development team. > > > > http://www.sqlite.org/cvstrac/chngview?cn=4399 > > -- > D. Richard Hipp [EMAIL PROTECTED] Isn't it time to drop the Win9X support from the default build? I'm thinking that any optimization should be enabled for the majority of users. Or if it's not really an optimization, why keeping it in the code then? If some people still need to compile for legacy OSes, they can always grab the source and compile without those optimizations. An alternative is to call this function when available using "GetProcAddress" (this is the case for a lot of other modern calls that cannot be done right now). Just my 2c Nicolas - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
=?ISO-8859-1?Q?Daniel_=D6nnerby?= <[EMAIL PROTECTED]> wrote: > Hi all! > > Tried upgrading to the 3.5.0 alpha from 3.4.2 using VS 2005 on XP. I > downloaded the ZIP with preprocessed C code. > Compiling SQLite to a .lib was no problem, but when linking it to an > ..exe I got the following: > sqlite.lib(mutex_w32.obj) : error LNK2019: unresolved external symbol > _TryEnterCriticalSection referenced in function _sqlite3_mutex_try > > I made some attempt to fix it checking all kind of possible errors on my > side (defines, compiler/linker settings etc) without any luck. > Anyone got the same error? > BTW. SQLite 3.4.2 works just fine. > > This is not a big deal for me to solve, just thought I share with the > development team. > http://www.sqlite.org/cvstrac/chngview?cn=4399 -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
Did you trying linking against kernel32.dll/lib ? http://msdn2.microsoft.com/en-us/library/ms686857.aspx --- Daniel Önnerby <[EMAIL PROTECTED]> wrote: > Tried upgrading to the 3.5.0 alpha from 3.4.2 using VS 2005 on XP. I > downloaded the ZIP with preprocessed C code. > Compiling SQLite to a .lib was no problem, but when linking it to an > .exe I got the following: > sqlite.lib(mutex_w32.obj) : error LNK2019: unresolved external symbol > _TryEnterCriticalSection referenced in function _sqlite3_mutex_try > > I made some attempt to fix it checking all kind of possible errors on my > side (defines, compiler/linker settings etc) without any luck. Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] 3.5.0 alpha TryEnterCriticalSection linker error
Hi all! Tried upgrading to the 3.5.0 alpha from 3.4.2 using VS 2005 on XP. I downloaded the ZIP with preprocessed C code. Compiling SQLite to a .lib was no problem, but when linking it to an .exe I got the following: sqlite.lib(mutex_w32.obj) : error LNK2019: unresolved external symbol _TryEnterCriticalSection referenced in function _sqlite3_mutex_try I made some attempt to fix it checking all kind of possible errors on my side (defines, compiler/linker settings etc) without any luck. Anyone got the same error? BTW. SQLite 3.4.2 works just fine. This is not a big deal for me to solve, just thought I share with the development team. Best regards Daniel - To unsubscribe, send email to [EMAIL PROTECTED] -
