> -----Original Message-----
> From: [email protected] [mailto:sqlite-users-
> [email protected]] On Behalf Of Andy Ling
> Sent: 27 June 2014 10:27
> To: '[email protected]'
> Subject: [sqlite] Building for vxWorks
>
I now have sqlite running under vxWorks. As nobody offered any suggestions, I
thought I would share my experience in the hope it will help others and maybe
feed some changes back into the main code.
> I am trying to build sqlite 3.8.5 for vxWorks 6.9 and I'm after a bit of help.
>
> To be more precise, I'm building an RTP for 64bit NEHALEM on vxWorks 6.9.3
>
> Straight out of the box it won't build, I get the following errors
>
> sqlite3.c:24997: error: expected specifier-qualifier-list before 'sem_t'
> sqlite3.c: In function 'fileHasMoved':
> sqlite3.c:25237: error: 'struct unixFileId' has no member named 'ino'
> sqlite3.c: In function 'semCheckReservedLock':
>
> The first I have fixed by adding a #include <semaphore.h>
semaphone.h is included if SQLITE_ENABLE_LOCKING_STYLE is defined, but I
couldn't get it to build with that set and it is required for the unixInodeInfo
structure so just before this structure definition I added
#if OS_VXWORKS
# include <semaphore.h>
#endif
> and the second
> I've fixed by bodging fileHasMoved to always return false.
I'm not sure what the "right" way is to fix this, but in our particular system
I don't think any files will get moved. So I have changed the function to look
like
static int fileHasMoved(unixFile *pFile){
#ifdef OS_VXWORKS
return 0 ;
#else
struct stat buf;
return pFile->pInode!=0 &&
(osStat(pFile->zPath, &buf)!=0 ||
buf.st_ino!=pFile->pInode->fileId.ino);
#endif
}
> It then builds, but has a few unresolved symbols. These I have fixed by
> adding the compile options
>
> -DHAVE_UTIME
> -DSQLITE_OMIT_LOAD_EXTENSION
>
I also had to bodge posixFchown. vxWorks doesn't support geteuid so I changed
this function to..
static int posixFchown(int fd, uid_t uid, gid_t gid){
#if OS_VXWORKS
return 0 ;
#else
return geteuid() ? 0 : fchown(fd,uid,gid);
#endif
}
> It now runs, but anything that tries to modify a database file generates a
> Disk
> I/O error.
>
After a bit of faffing I eventually found this was a problem with unlink.
Sqlite was trying to delete a temporary file using unlink. If the error from
unlink was ENOENT it ignored it assuming the file had been deleted (or not
created).
vxWorks only supports the POSIX error codes if you are using a POSIX compliant
filing system. We're using dosFs, which isn't. So the error returned by unlink
wasn't ENOENT.
I have fixed this by adding a new compile option "USING_DOSFS" and changed
delete to..
static int unixDelete(
sqlite3_vfs *NotUsed, /* VFS containing this as the xDelete method */
const char *zPath, /* Name of file to be deleted */
int dirSync /* If true, fsync() directory after deleting file */
){
int rc = SQLITE_OK;
UNUSED_PARAMETER(NotUsed);
SimulateIOError(return SQLITE_IOERR_DELETE);
if( osUnlink(zPath)==(-1) ){
#if OS_VXWORKS && USING_DOSFS
if ( errno == S_dosFsLib_FILE_NOT_FOUND )
#else
if( errno==ENOENT )
#endif
{
rc = SQLITE_IOERR_DELETE_NOENT;
}else{
This also requires the dosFsLib.h file being included and there seems to be
some incompatibilities somewhere which mean it didn't quite work. I didn't have
the time to investigate properly so added this bodge..
#if OS_VXWORKS && USING_DOSFS
/* copied from vwModNum.h */
# define M_dosFsLib (56 << 16)
# define IMPORT extern
# include <dosFsLib.h>
#endif
My compile options are now....
-DHAVE_UTIME -DSQLITE_OMIT_LOAD_EXTENSION -DUSING_DOSFS
The next problem I encountered was running sqlite commands from the vxWorks
shell. Invariably they crashed in some way. This was because the stack is too
small in the shell. So making the commands spawn a thread with a bigger stack
(64K was enough) fixed this.
So I now have enough running to start doing some real work.
Regards
Andy Ling
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
