I decided to use sqlite3 with Dev C++.
At the top of the sample code, it includes <sqlite3.h>
The sqlite3 binary download comes with the following files:
sqlite3.dll
sqlite3.def
another download includes te sqlite3.exe
Correct me if I'm wrong, but I'm guessing there is a method for me to some how use this dll and def file and simply link or use it as an include some how.
Any thoughts on that ?
I don't know much about this type of info.
I tried using reimp on the dll but that didn't work.
thanks in advance.
stev
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-07-31
YIu need an export library. reimp converts Microsoft Export libraries to GNU, but you still need the export. Alternatively you can use teh LoadLibrary and GetProcAddress calls.
All you need is to include the sqlite3.h file in your's source, and put the corresponding sqlite3.dll in Project options -> Parameters -> Linker window. No def or export library is needed if You use the Dev-C++ GNU tools chain.
Old Newbie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-07-31
Eh?
That is only true if you use LoadLibrary/GetProcAddress. Otherwise how will the executable link? The symbols must be present to resolve the external references.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just now I'm involved in a work with some Boost librarys and SQLite 3.4.0 in Dev-C++ 4.9.9.2 but with the MinGW-5.1.3.exe (2006-12-20).
Before send the preceding post, I renamed the sqlite3.def file (actually in the project directory) and do a rebuild in the project without complains. After that I tested the resulting exe.
Unless I'm using the .def file inadvertently, the things work this way.
I believe to remember have read in some place that if the DLL and .EXE are built with the GNU-chain, is not necessary the presence of the definition file for the construction of the executable.
Anyway, you can download the mentioned library and run a test in the same circumstances.
Old newbie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"With the latest versions you can simply link the Microsoft libraries, both '.LIB' and '.DLL', directly."
I hadn't been kidding.
"I believe to remember [...] of the executable."
Well, what suite created the DLL is of little matter.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-01
>> Uh, Clifford, you was told of this same feature very recently.
I was under the impression that merely meant you could use an MS .lib file, Old Newbie is suggesting that you don't need and export at all. Is that correct? What does the linker use to resolve symbols in this case?
>> "With the latest versions.."
Does that include the version with provided Dev-C++? If not, then the answer is still reasonable, and upgrading the toolchain an alternative solution.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, there are some caveats, but mostly that is correct.
So long as the '.DLL' is fairly self-contained linking the '.DLL' directly, without any reference to the '.LIB' or '.DEF', is fine.
There are obviously problems with shared data, bizarre methodology, and C++ ABI issues.
If the suite that generated the '.DLL' doesn't do anything weird with the symbol table then LD can handle it, basically if the 'GetProcAddress' approach would work, including COM stuff, but I have no understanding of the exact methods used.
"Does that include the version with provided Dev-C++?"
No clue; I haven't used the version that actually comes with Dev-C++ in years.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-01
Fair enough. I reckon the DevPak approach is the path of least resistance; bit since I have no interest in SQL I am not about to try either solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I decided to use sqlite3 with Dev C++.
At the top of the sample code, it includes <sqlite3.h>
The sqlite3 binary download comes with the following files:
sqlite3.dll
sqlite3.def
another download includes te sqlite3.exe
Correct me if I'm wrong, but I'm guessing there is a method for me to some how use this dll and def file and simply link or use it as an include some how.
Any thoughts on that ?
I don't know much about this type of info.
I tried using reimp on the dll but that didn't work.
thanks in advance.
stev
YIu need an export library. reimp converts Microsoft Export libraries to GNU, but you still need the export. Alternatively you can use teh LoadLibrary and GetProcAddress calls.
You should be able to get all you need specifically for Dev-C++ from http://www.devpaks.org/category.php?category=Database
Clifford
All you need is to include the sqlite3.h file in your's source, and put the corresponding sqlite3.dll in Project options -> Parameters -> Linker window. No def or export library is needed if You use the Dev-C++ GNU tools chain.
Old Newbie
Eh?
That is only true if you use LoadLibrary/GetProcAddress. Otherwise how will the executable link? The symbols must be present to resolve the external references.
Clifford
Just now I'm involved in a work with some Boost librarys and SQLite 3.4.0 in Dev-C++ 4.9.9.2 but with the MinGW-5.1.3.exe (2006-12-20).
Before send the preceding post, I renamed the sqlite3.def file (actually in the project directory) and do a rebuild in the project without complains. After that I tested the resulting exe.
Unless I'm using the .def file inadvertently, the things work this way.
I believe to remember have read in some place that if the DLL and .EXE are built with the GNU-chain, is not necessary the presence of the definition file for the construction of the executable.
Anyway, you can download the mentioned library and run a test in the same circumstances.
Old newbie
By the way, perhaps this link may be of interest
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg26519.html
Old Newbie
Uh, Clifford, you was told of this same feature very recently.
http://sourceforge.net/forum/message.php?msg_id=4419380
"With the latest versions you can simply link the Microsoft libraries, both '.LIB' and '.DLL', directly."
I hadn't been kidding.
"I believe to remember [...] of the executable."
Well, what suite created the DLL is of little matter.
Soma
>> Uh, Clifford, you was told of this same feature very recently.
I was under the impression that merely meant you could use an MS .lib file, Old Newbie is suggesting that you don't need and export at all. Is that correct? What does the linker use to resolve symbols in this case?
>> "With the latest versions.."
Does that include the version with provided Dev-C++? If not, then the answer is still reasonable, and upgrading the toolchain an alternative solution.
Clifford
"I was under the [...] symbols in this case?"
Well, there are some caveats, but mostly that is correct.
So long as the '.DLL' is fairly self-contained linking the '.DLL' directly, without any reference to the '.LIB' or '.DEF', is fine.
There are obviously problems with shared data, bizarre methodology, and C++ ABI issues.
If the suite that generated the '.DLL' doesn't do anything weird with the symbol table then LD can handle it, basically if the 'GetProcAddress' approach would work, including COM stuff, but I have no understanding of the exact methods used.
"Does that include the version with provided Dev-C++?"
No clue; I haven't used the version that actually comes with Dev-C++ in years.
Soma
Fair enough. I reckon the DevPak approach is the path of least resistance; bit since I have no interest in SQL I am not about to try either solution.
"I reckon [...] least resistance"
Almost certainly.
Soma