> -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Andy Ling > Sent: 27 June 2014 10:27 > To: 'sqlite-users@sqlite.org' > 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users