Compiling SQLite RTREE in MSVC? - sqlite

I need to compile the rtree extension for SQLite from source code. The readme includes these instructions:
The easiest way to compile and use the RTREE extension is to build
and use it as a dynamically loadable SQLite extension. To do this
using gcc on *nix:
gcc -shared rtree.c -o libSqliteRtree.so
You may need to add "-I" flags so that gcc can find sqlite3ext.h
and sqlite3.h. The resulting shared lib, libSqliteRtree.so, may be
loaded into sqlite in the same way as any other dynamicly loadable
extension.
Problem I'm having is that I'm on Windows, not Linux, and so need to use MSVC. I tried:
cl rtree.c -link -out:libSqliteRtree.so
This gave cannot open include file errors until I found the various .h files it was complaining about and moved them into the same directory. Now, however, it's gotten to:
/out:rtree.exe
-out:libSqliteRtree.so
rtree.obj
Creating library libSqliteRtree.lib and object libSqliteRtree.exp
LINK : fatal error LNK1561: entry point must be defined
I admit I have pretty much zero clue what I'm doing in a compiler, and I'm not sure where to go from here to resolve its problem. Am I "translating" the compiler flags correctly from GCC to MSVC? What else can I tweak to try to get the SQLite extension out of the source code? Should I beg a favor from a developer on ateam with a Linux server and ask them to do it for me?

Thanks to Shawn for commenting to look at the SQLite Run-Time Loadable Extensions documentation, which had more information in it:
To compile on Windows using MSVC, a command similar to the following will usually work:
cl YourCode.c -link -dll -out:YourCode.dll
So for my situation: cl rtree.c -link -dll -out:libSqliteRtree.dll worked.

Related

Compiling and Linking against plplot library on debian

I am using Code::Blocks IDE on Debian 8. I have installed the plplot library form synaptic (not from source). When I create new project in C::B and try to run a simple plplot example the compiler do not recognize the includes and the linker do not recognize the plplot library. So how to compile and link with plplot library when I have installed it from Synaptic not from source? Is this possible, or I should remove current packages and install from source only?
In general when I install new library (from synaptic or from source) how to find out what should be the compiler flags and search directories and for the linker too? I think installing from source should be the less problems prone way!
Till now I am doing file search for the included header and add its directory to the search path for the compiler. But this is very cumbersome and naive approach. It will be better if I add compiler flag that does all this job, but how to find it out. Some flags I find in forums but not in the documentation of the libraries. Why there is no file with the third program library to tell what flags should one use? Nevertheless when the o files are done I have linker errors like "undefined reference to...".
For the plplot library the linker flag should be -lplplotd. For the compiler options I have no flags but I did a search for the unknown headers and added their directories to the search directories path. Now the Example 00 works fine. Though I found the -lplplotd flag by shooting! For the x11 examples one should add the flag -lplplotcxxd.
In general I got that to find the linker flag I have to search for the library so file and the name of the file commonly is the flag, e.g. for the library libplplotcxxd.so the flag is -lplplotcxxd.
Anyway, I'd be glad if someone tells me a better clue on finding these linker flags.

sqlite3 can't loading extension

I am trying to load an extension in sqlite3.
I managed to compile the extension using:
clang -bundle -fPIC -Isqlite3 -o <desired extension name>.sqlext <filename>.c
However, I cannot seem to load the extension.
.load <path to extension file>
Error: unknown command or invalid arguments: "load". Enter ".help" for help
And when I type .help, I cannot see .load.
I have also tried to enable extensions.
int sqlite3_enable_load_extension(sqlite3 *db, int onoff==1);
Error: near "int": syntax error
I would really appreciate a step-by-step instruction on how to enable extensions in SQLite?
Thanks!
Most likely your sqlite compiled with SQLITE_OMIT_LOAD_EXTENSION. Get the one build without this flag, or build it yourself.
You cannot use sqlite3_enable_load_extension from SQL, it is sqlite's C API.
For many vendors, the default provided sqlite3 does not have a load extension enabled. (keltar clarified)
I would really appreciate a step-by-step instruction on how to enable extensions in SQLite?
Go to Sqlite Downloads
Get the appropriate build. It has the load extension enabled.
Use it directly or replace /usr/bin/sqlite3 with the newer one.

table_editors-moc.ads not found

I'm using gcc (GCC) 4.5.4 20120510 for GNAT GPL 2012 (20120509)
and qtada from qtada-gpl-3.2.0-20120708-3871-qt4.8.2-2.exe installer.
I'm trying to compile example from "..\GNAT\2012\examples\qtada\sql\cached_table", but it say "table_editors-moc.ads not found",
The error came from statement :
with Table_Editors.MOC; pragma Warnings (Off, Table_Editors.MOC);
-- Child package MOC must be included in the executable.
Where can i found the "Child package MOC" that contains "table_editors-moc.ads" and another moc file??
I don't know Qt or QtAda, but a quick search indicates that Qt uses a Meta Object Compiler (MOC) to auto-generate source code from macros. Could it be that your Table_Editor.MOC is supposed to be generated?
I'm surprised that QtAda has installed its examples at \GNAT\2012\examples; judging by the way GNAT is set up on this Mac, I'd have expected \GNAT\2012\share\examples.
However .. I suspect that QtAda's file system layout is complicated enough that you'll need to use a "GNAT Project file" to do the build. I hope there's a .gpr file in the same directory as your example code (if not, I can't help); if so, and assuming it's called cached_table.gpr, then in a command window say
gnatmake -p -P cached_table.gpr
or (following the documentation for QtAda 3.1)
gprbuild -p -P cached_table.gpr

Compiling sqlite Levenshtein function for System.Data.SQLite

OK, I'm new to compiling programs, and I have literally tried everything.
I downloaded System.Data.SQLite from here:
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
This allowed me to get sqlite functionality into my C# application. Now I'm looking to add a Levenshtein function so that I can do a search to find similar results in my c# application.
I stumbled upon:
https://github.com/mateusza/SQLite-Levenshtein
But I honestly have no clue how to compile it and load it as an extension. I read about the sqlite extensions on sqlite's main website.
I have an idea about how to load my extension: Run select load_extension('path to .dll'), but I don't know how to turn that SQLite-Levenshtein into a dll file that can be loaded from sqlite. I would appreciate any help you can give. (Please bear with me, I'm slowly diving into wide world of compiling).
That's how I compiled this extension with mingw GCC:
gcc -s -O4 -I /path/to/sqlite/headers/ -shared -o levenshtein.dll levenshtein.c
/path/to/sqlite/headers/ is the place where sqlite3ext.h file is located.
If your platform is x86 (32-bit), you may take http://www.siftsoft.com/misc/levenshtein.dll -- that's what I built from git HEAD right now.

mingw ignores '-L' flag

I am getting linker failures under MinGW, however I cannot see why. This is the link command:
g++ -shared -mthreads
-Wl,--out-implib,C:\Users\camm\Syren\libs\libSy_polyMesh.a -o C:\Users\camm\Syren\libs\Sy_polyMesh.dll debug/Sy_polyMesh.o
debug/moc_Sy_polyMesh.o debug/qrc_Sy_polyMesh.o -L"c:\Qt\4.8.4\lib"
-lglu32 -lopengl32 -lgdi32 -luser32 -LC:\Users\camm\Syren/libs -lSyren -lglew32 -lboost_system -lQtSvgd4 -lQtSqld4 -lQtOpenGLd4 -lQtGuid4 -lQtCored4
The undefined reference errors come from the Syren dll (I should state the command was automatically generated by qmake). The -LC:\Users\camm\Syren/libs looks malformed to me because of the mix of forward and backslashes, but if I manually set them to all one way or the other - it does not change the compiler output.
I had earlier problems with 3rd party libraries I needed (GLEW and Boost specifically), but because they were relatively 'constant' I didn't have a problem putting them in my C:\MinGW\lib directory. But that is really not an option for my plugins.
What I find is that the MinGW docs state in a few locations:
...since suitable search paths may always be specified using -L
options.
...but that GCC itself furnishes the effective defaults, by supplying
appropriate -L options.
However, C:\Users\camm\Syren\libs is where Syren.dll resides!
Edit: Here are the LIBS declarations in my .pro file:
LIBS += -L$(SYREN_PATH)/libs \
-lSyren
win32 {
LIBS += -lglew32 \
-lboost_system
}
And $(SYREN_PATH) expands to C:\Users\camm\Syren. Also I can see to the 'missing' symbols in Syren.dll, for example:
C:\Users\camm\Documents\Syren\Sy_polyMesh_debug/../Sy_polyMesh/src/Sy_polyMesh.cpp:341:
undefined reference to `Sy_GLBuffer::unbind()'
Can be seen listed as:
6c500bd6 T _ZN11Sy_GLBuffer6unbindEv
Edit2
After adding a verbose flag to the linker stage I noticed that the linker was iterating through each search path and then through each library naming convention, and using the first one it could open.
attempt to open C:\Users\camm\Syren/libs/libSyren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/Syren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/libSyren.a succeeded
Hypothesizing that the libSyren.a may be broken, I renamed it to force the linker to use the .dll:
attempt to open C:\Users\camm\Syren/libs/libSyren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/Syren.dll.a failed
attempt to open C:\Users\camm\Syren/libs/libSyren.a failed
attempt to open C:\Users\camm\Syren/libs/Syren.lib failed
attempt to open C:\Users\camm\Syren/libs/libSyren.dll failed
attempt to open C:\Users\camm\Syren/libs/Syren.dll succeeded
But I still get exactly the same error messages!
If you are linking the right DLL and the linker isn't complaining about a missing file, the dll might be missing exports to allow linking.
The MinGW linker can link directly to a DLL if it properly exports the symbols, although it is still recommended to link to the import library (which should be created in a qmake build) which is named lib*.a or lib*.dll.a. I believe the linker looks for variants with and without the libprefix, but I am unsure and should test this myself.
You can check what symbols a DLL exports by using objdump and/or nm.
If the linker doesn't complain about not being able to load Syren dll, it means that the file is correctly loaded... The symbols are just missing into the Syren dll (not exported ?)... Why it's hard to tell without more information
When you built the Syren lib, did you have any warning about missing prototypes ?
What is used by Syren lib, nothing not portable or requiring a Windows dll ?
Could you give the list of missing symbols ?
Edit : How do you compile the Syren.dll ? Did you use Mingw ? What option did you pass to the compiler / linker ?
I suggest to read these 2 links :
http://www.mingw.org/wiki/sampleDLL
http://www.mingw.org/wiki/CreateImportLibraries
If you are exporting C++ function you must use the same compiler between the program and the DLL. Or you could use a C-style wrapper functions to encapsulate the C++ ABI.
A very good article about this subject : http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
What happens when you replace $(SYREN_PATH) with $${SYREN_PATH}?
Because the former notation $() means the contents of an environment variable at the time Makefile is executed.
See the qmake variable reference.

Resources