Re: [sqlite] SQLite does not support ARM platform?
This is a Visual Studio/Microsoft issue. We have been building SQLite on ARM 7 and 9 for almost ten years across a wide variety of (non-Microsoft) operating systems. V. From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf of Jaime Stuardo [jstua...@desytec.com] Sent: Monday, March 20, 2017 4:24 PM To: 'SQLite mailing list' Subject: [sqlite] SQLite does not support ARM platform? Hello, I have finally given up. After almost all day trying to compile SQLite amalgamated source code files for ARM platform I got the conclusion that SQLite is not for ARM platform, even when documentation says the contrary. I have VS 2008 and I tried to compile some C++ wrappers out there that contains amalgamated files but with no success I tried several command line parameters, but nothing. Last try was, by using only amalgamated files (shell.c, sqlite3.c, sqlite3.h, sqlite3ext.h). There is no science with this. I open a VS2008 command prompt and VS2012 ARM Command prompt and compile with: "cl sqlite3.c -link -dll -out:sqlite3.dll -machine:ARM" In both cases, I got this error: "crtdefs.h(338) : fatal error C1189: #error : Compiling Desktop applications for the ARM platform is not supported." That took me to the conclusion about SQLite is only for Desktop applications, which is very bad. Is there another alternative or trick to make it compile for ARM platform? Thanks Jaime ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users This message is for the addressee's use only. It may contain confidential information. If you receive this message in error, please delete it and notify the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no responsibility for viruses which may infect an email sent to you from Tripp Lite and which damage your electronic systems or information. It is your responsibility to maintain virus detection systems to prevent damage to your electronic systems and information. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select * on empty virtual table
We have tried a null pointer, a zero-length static, a dummy static and strings created on the heap via sqlite3_mprintf. All cause the same segmentation fault. V. From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Drake Wilson [dr...@begriffli.ch] Sent: Friday, April 29, 2011 10:30 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] select * on empty virtual table Quoth Joseph Stockman <joseph_stock...@tripplite.com>, on 2011-04-29 15:14:07 +: > My apologies. No worries. > We set idxNum to zero, idxStr to NULL, needToFreeIdxStr to zero, > orderbyConsumed to zero and estimatedCost to 1000. But that still looks a bit wonky; I don't see anywhere in the virtual table docs that idxStr is allowed to be NULL rather than a string. (I interpret the opaqueness to mean that the string contents are opaque, not the pointer itself.) needToFreeIdxStr just distinguishes between a string on the heap and a presumed-static string for the purposes of memory ownership. Does this still fail if you use an empty string or other recognizable non-NULL sentinel string instead? ---> Drake Wilson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select * on empty virtual table
It never reaches the xOpen call.
V.
From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Jay A. Kreibich [j...@kreibi.ch]
Sent: Friday, April 29, 2011 10:47 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] select * on empty virtual table
On Fri, Apr 29, 2011 at 03:14:07PM +, Joseph Stockman scratched on the wall:
> My apologies.
>
> We set idxNum to zero, idxStr to NULL, needToFreeIdxStr to zero,
> orderbyConsumed to zero and estimatedCost to 1000.
The sqlite3_index_info struct is zero-ed out before it is passed to
your function. As such, it essentially provides default values for
almost everything. I have a large number of virtual table adapters
that use this code:
static int xBestIndex ( sqlite3_vtab *vtab, sqlite3_index_info *info )
{
return SQLITE_OK;
}
> We never get to our xFilter method; sqlite throws the segmentation
> fault internally trying to process the result of the xBestIndex call.
You should get a call to xOpen() before you get to xFilter().
xBestIndex() is a "table-level" call, while xFilter() is a
"cursor-level" call. What is the status of your xOpen() call?
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Intelligence is like underwear: it is important that you have it,
but showing it to the wrong people has the tendency to make them
feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] select * on empty virtual table
My apologies. We set idxNum to zero, idxStr to NULL, needToFreeIdxStr to zero, orderbyConsumed to zero and estimatedCost to 1000. We never get to our xFilter method; sqlite throws the segmentation fault internally trying to process the result of the xBestIndex call. V. From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Drake Wilson [dr...@begriffli.ch] Sent: Friday, April 29, 2011 10:07 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] select * on empty virtual table Quoth Joseph Stockman <joseph_stock...@tripplite.com>, on 2011-04-29 14:50:51 +: > Our trace shows that we enter our xBestIndex method, see that > both nConstraints and nOrderBy are zero, so we return without > modifying any of the structures. So essentially you're returning all undefined values? That doesn't seem like a valid thing to do. Presumably you should set the result values to indicate "no constraints used, no ordering consumed, an arbitrary high cost estimate, and an indicator for full-scan access (that will be recognized by the xFilter method)", no? ---> Drake Wilson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] select * on empty virtual table
I have looked for a reason or solution to this problem but can't seem to find one anywhere. We are running sqlite in a cross-platform environment (Windows, Linux and an embedded system). This error appears across the board. We are implementing our first set of virtual tables. After xCreate is called successfully, we test the table by running a "select *" query. Our trace shows that we enter our xBestIndex method, see that both nConstraints and nOrderBy are zero, so we return without modifying any of the structures. And then comes the segmentation fault in the sqliote3DbFree call within the vtabBestIndex method. Am I missing something obvious? V. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
