How to integrate sqlite3 C++ interface - c++

I'm trying to use SQLite3 for database managing in my little project on Windows, I just made some C++ code to generate my database but I can't link my code with the "sqlite3.h" file, no matter if I use
#include <sqlite3.h>
compiling with
g++ DBconfig.cpp -l sqlite3
(in that case the compiling error is "fatal error: sqlite.h: no such file or directory").
I can't either use
#include "path/sqlite3.h"
Tried compiling in many ways, results in tons of declared but not defined things like the function "sqlite_exec()".
Everywhere people fix this easily by using a linux "sudo" command or downloading and compiling sqlite3 libraries, I tried that, nothing removes these errors. I have SQLite 3 installed, along with its interface (https://www.codeproject.com/Articles/6343/CppSQLite-C-Wrapper-for-SQLite) files that I ran with "lib /def:" command.
Internet tutorials say just installing sqlite3, including the first way I did and compiling with "-l sqlite3" should work.

Related

IWYU failing/unclear output?

I recently installed include-what-you-use (IWYU) to try it out. I am on version include-what-you-use 0.12 based on clang version 9.0.1-10. (My OS is Ubuntu 20.04 on WSL1)
I tried to do a very simple example on a source code file, but it quickly comes back as an error on the very first include? (Which is just a c standard library file)
After running
include-what-you-use myutils.cpp:
In file included from myutils.cpp:8:
In file included from ./myutils.h:11:
/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/cfloat:42:10: fatal error: 'float.h' file not found
#include <float.h>
^~~~~~~~~
Why is it error'ing out on a c standard library include?
I cannot post the entire source here, and without extensive testing I am not sure what minimal example would cause this problem.
Am I just mis-using IWYU? I installed it via apt rather than building it and llvm/clang/etc from scratch. Is that fine?

How to solve comiler error: 'v_bias' is not a namespace-name

Sort briefing what I am trying to do:
I want to use vnode-lp on my windows PC. I’ve installed MinGW. I’ve installed the necessary dependencies like LAPACK & BLAS libraries as well as Profil/BIAS. The installation of all libraries passed the make and make install process without errors. I hope (!) I’ve managed to install it correctly.
Now the Problem:
Now I’ve tried to get a simple program compiled with basically northing in it just an #include “vnode.h”. First I tried it with Microsoft Visual Studio. Since this gave me several errors I tried to compile it with g++ using MinGW. This gives me the same errors. It starts with
./matrix.w:90:17: error: ‘v_bias’ is not a namespace-name
The Question:
How to include vnodelp into an c++ program and compile it without errors under windows, am I missing something?
Off-topic:
I am trying to get this running for over a week now and don’t know what to do anymore.
C++ is most definitely not C, and packages designed for C++ will never compile and run as C code. So, what you're trying to do really can't be done unless you do some fancy stuff by creating a .dll or something like that, and even then I think you wouldn't get the functionality you want. Why not write your code in C++ and compile with g++ or a similar compiler?
I have managed to finally solve this issue. In case someone has the same problem here is the solution.
I have missed something in the call. Here is the full call that has worked for me:
g++ -o2 –Wall –Wno-deprecated –DNDEBUG – DPROFIL_VNODE – DMAXORDER=50 –I(path to profil bias)/include –I(path to profil bias)/include/BIAS –I(path to profil bias)/src/Base –I(path to vnodelp)/FADBAD++ -I../include –DNDEBUG –c –o (filename).o (filename).cc
g++ -L(path to profil bias)/lib –L(path to lapack)/lib –L../lib –o (filename) (filename).o –lvnode –lProfil –lBias –llr (path to lapack)/lib/liblapack.lib (path to lapack)/lib/libblas.lib –lstd++
funfact:
This also complies with gcc instead of g++

gcc and clang under msys2 cannot resolve includes with absolute paths

I try to get tests generated by the cxxtest framework working under a MinGW environment managed by mysys2. The tool generates C++ files with absolute paths. However, gcc seems to be unable to resolve this absolute paths.
Here is a minimal example to demonstrate the problem:
// file1.h
#include <iostream>
inline void hallo() { std::cout << "Hallo\n"; }
// main.cpp
#include "/home/phil/example/file1.h"
int main()
{
hallo();
return 0;
}
The file exists (at least the msys2 shell resolves the path):
$ ls /home/phil/example/file1.h
/home/phil/example/file1.h
... but calling g++ results in this error:
$ g++ main.cpp
main.cpp:1:38: fatal error: /home/phil/example/file1.h: No such file or directory
#include "/home/phil/example/file1.h"
^
compilation terminated.
Same error with clang.
Under a full Linux environment, the example works. It also works if I replace the absolute path by a relative one (#include "file1.h").
So, I assume the problem lies in the layer over Windows that is responsible to resolve paths. Not sure whether I should report it as a bug to the msys2 project, or whether it is a known problem. If it is a known problem, are there any workarounds (like setting -I options)?
(If possible, I would like to avoid replace the absolute paths, as they are in generated code by the cxxtest framework. Technically, running a postprocessing step on the generated files would be possible but seems like a hack in the long run.)
Since you are running compilers that use MinGW-w64 as their runtime environment, they don't recognize POSIX-style paths like that. I think they actually interpret the root directory "/" to be "C:\". Other than that, they would only recognize native Windows-style paths.
I recommend that you pass the argument -I/home/phil/example to your compiler from some program running in the msys-2.0.dll POSIX emulation runtime environment (e.g. /usr/bin/bash or /usr/bin/make). The msys-2.0.dll runtime will then convert that argument to use a native Windows path so the compiler can understand it, and statements like #include <file1.h> will work. Alternatively, you might try putting a Windows-style path in your source code, e.g. the path should start with C:\.
Note however that having absolute paths in source code or build scripts is a bad idea since it makes it harder to build the code on a different computer. You could consider using environment variables or relative paths.
Try using the MinGW compiler that Cygwin provides as a package. (In other words, forget the MSYS environment; work under Cygwin, but build the code as before, in the MinGW style.)
Then you should be able to have include references /home/phil; it will just resolve to C:\Cygwin\home\phil or wherever your Cygwin root is.
Actually, it might be possible under MSYS also (which, after all, is just the descendant of an old for of Cygwin). You just have to figure out what /home/phil is referring to, create that tree and work under there.

Compilation error: "stddef.h: No such file or directory"

Whenever I try to compile this code it always ends up with this error:
In file included from /usr/include/wchar.h:6:0,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cwchar:44,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iosfwd:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ios:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iostream:39,
from test.cpp:1:
/usr/include/sys/reent.h:14:20: fatal error: stddef.h: No such file or directory
#include <stddef.h>
^
compilation terminated.
The code I was trying to compile is:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World! :D";
return 0;
}
The error is because your gcc-core package and gcc-g++ are not of the same version. Either downgrade one of them to solve the problem or update both the libraries. Updating both the libraries is the recommended way.
I had this error on a fresh MinGW install, it had nothing to do with the installed packages mentioned in the current accepted answer by "Prasanth Karri". In my case the issue was caused by -nostdinc in my Makefile. I actually only needed that compiler flag when building for a different target platform (not when using MinGW) so I fixed the issue by removing that flag from MinGW builds.
When I was incorporating a software library written in C into an existing demo project(used a C++ mbed library) I encountered this problem. The demo project would compile just fine, but after I replaced the existing main file by my own, this error occurred.
At this point I hadn't yet thought about the fact that the mbed library that I needed was written in C++. My own main file was a .c file that #include the mbed header file. As a result I used my normal C source as if it was a C++ source. Therefore the compiler that was used to compile my main file was the C compiler.
This C compiler then encountered a #include of a module that actually does not exist (within its scope), as it's not a C++ compiler.
Only after I inspected the output of the build log I realised the various source C and C++ files were compiled by more that 1 compiler(the c++ compiler). The project used used compilers arm-none-eabi-c++ and arm-none-eabi-gcc (for embedded systems) as seen below.
Compile log:
Building file: ../anyfile.cpp
Invoking: MCU C++ Compiler
arm-none-eabi-c++ <A lot of arguments> "../anyfile.cpp"
Finished building: ../anyfile.cpp
Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc <A lot of arguments> "../main.c"
In file included from <Project directory>\mbed/mbed.h:21:0,
from ../main.c:16:
<Project directory>\mbed/platform.h:25:19: fatal error: cstddef: No such file or directory
compilation terminated.
Of course in a C++ environment cstddef exists, but in a C environment cstddef doesn't exist, in stead it's just C's implementation of stddef.
In other words, cstddef does not exist in the C compiler.
I resolved this problem by renaming my main.c file to main.cpp and the rest of the code compiled smoothly too.
TLDR/Conclusion: When building a C++ project, avoid mixing C files with C++ files(sources and headers). If possible rename .c files to .cpp files to use the C++ compiler in stead of the C compiler where required.
In order to update it, follow below.
If you are on Windows, just run these on command prompt or powershell
Update the package list: mingw-get update
After updating the package list, run: mingw-get upgrade
Source: How to update GCC in MinGW on Windows?
This problem was solved for me as I installed codeblocks with mingw compiler then I copied the mingw folder from codeblocks to C drive and added
C\mingw\bin to the environment variables.
If you try to compile and see a message like, "fatal error: stddef.h: No such file or directory", the error is because your gcc-core and gcc-g++ packages are not of the same version. Rerun the Cygwin install and make sure that you select the highest numbered versions of gcc-core and gcc-g++.
After installing the C++ compiler with MinGW I encountered this problem as well. Apparently, you have to also install mingw32-base. Go to C:/MinGW/bin/mingw-get.exe (my path) and check it for installation at the Basic Setup tab.

How do I use a shared dynamic library in c++ project?

I am running 64bit Linux and using Netbeans 8.0 IDE. I simply created new C++ project, so far only containing some HelloWorld code. I want to use a third party library for logging. I chose log4cpp (since I have experience with Java and it is supposed to have similar interface).
I installed liblog4cpp from the repositories, and can see it in /usr/lib, to be clear:
$ locate log4cpp
/usr/lib/liblog4cpp.so
/usr/lib/liblog4cpp.so.5
/usr/lib/liblog4cpp.so.5.0.5
/usr/lib/x86_64-linux-gnu/liblog4cpp.so
/usr/lib/x86_64-linux-gnu/liblog4cpp.so.5
/usr/share/doc/liblog4cpp5
/usr/share/doc/liblog4cpp5/AUTHORS
/usr/share/doc/liblog4cpp5/NEWS.gz
/usr/share/doc/liblog4cpp5/README
/usr/share/doc/liblog4cpp5/THANKS
/usr/share/doc/liblog4cpp5/TODO
/usr/share/doc/liblog4cpp5/changelog.Debian.gz
/usr/share/doc/liblog4cpp5/changelog.gz
/usr/share/doc/liblog4cpp5/copyright
/var/cache/apt/archives/liblog4cpp5_1.0-4_amd64.deb
/var/lib/dpkg/info/liblog4cpp5.list
/var/lib/dpkg/info/liblog4cpp5.md5sums
/var/lib/dpkg/info/liblog4cpp5.postinst
/var/lib/dpkg/info/liblog4cpp5.postrm
/var/lib/dpkg/info/liblog4cpp5.shlibs
I am having big trouble on how to #include it in my application. Inspired by example from the documentation I put in my source:
#include "log4cpp/Category.hh"
#include "log4cpp/Appender.hh"
#include "log4cpp/FileAppender.hh"
#include "log4cpp/OstreamAppender.hh"
#include "log4cpp/Layout.hh"
#include "log4cpp/BasicLayout.hh"
#include "log4cpp/Priority.hh"
I was first using Makefile generated by netbeans, however could not figure out how to configure the project to make it work. All my trials lead to the following error (line 16 being the first #include):
$ make
src/main.cpp:16:31: fatal error: log4cpp/Category.hh: No such file or directory
compilation terminated.
make: *** [build/NetworkConfiguration.o] Error 1
I also tried a custom Makefile, giving g++ argument -llog4cpp, but I always get the same error. I can provide more info/code if it will be helpful. The solution does not need to depend on the IDE, I feel like I just misunderstood how linking works, so feel free to educate me on how to achieve what I want from console with custom Makefile for example.
Since cup still has not posted an answer, I am paraphrasing his comment as an accepted answer.
Install liblog4cpp-dev. The difference is that liblog4cpp only contains the libraries while liblog4cpp-dev is the development kit which includes the headers.