I'm trying to embed lua in a c program, but I'm having problems to compile the code. I have installed everything lua 5.2 related in synaptic and when tried to compile this:
extern "C"{
#include <stdio.h>
#include <string.h>
#include "lua5.2/lua.h"
#include "lua5.2/lauxlib.h"
#include "lua5.2/lualib.h"
}
int main(int argc, char* argv[])
{
lua_State *lua_state;
lua_state = luaL_newstate();
lua_close(lua_state);
}
and compile using
g++ main.cpp -llua
show the folowing errors
Could not find -llua
what do?
There are tools you can use to find the proper compiler / linker switches for a library.
In particular, with a proper installation of the lua5.2 libraries you can use
pkg-config -libs lua5.2
On my system it outputs
-llua5.2
Use this, or the output of pkg-config (backticked) as your linkers argument.
Of course, pkg-config can also tell you the -CFLAGS for the package with
pkg-config --cflags lua5.2
The man page is quite readable.
Related
As I'm rather new to Cmake usage, I don't really know how to solve this problem. In my C++ code, I use functions from the Linux i2c library, as follows:
extern "C" {
#include <linux/i2c-dev.h>
#include <i2c/smbus.h>
}
#include <sys/ioctl.h>
#include <string.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdint.h>
bool cpi2c_writeRegister(uint8_t address, uint8_t subAddress, uint8_t data) {
return i2c_smbus_write_byte_data(address, subAddress, data) == 0;
}
I usually compile with Cmake using CMakeLists, but now it doesn't work since it states: undefined reference to 'i2c_smbus_write_byte_data'. I tried with G++ to link dynamically:
g++ -std=c++11 -Wall -c main.cpp
g++ -std=c++11 -o Main main.o -li2c
This worked well and there are no problems. The problem is I really need to compile with CMakeLists, so do you know a way how to achieve this? Cmake does not find the package by default (since it has no .config-file) and I don't know where the functions from i2c/smbus.h are defined.
Thanks for your help!
Using pkg-config is generally preferred to link libraries that have a .pc file.
But as libi2c does not seem to install a .pc file you can use target_link_libraries() directly by providing the library name. For simplicity and portability use the "Plain library name" (see the target_link_libraries documentation).
target_link_libraries(main i2c)
CMake will take care of expanding the plain library name to -li2c, i2c.lib, or whatever is suited to your build environment and operating system.
Step 1: add
target_link_libraries(${PROJECT_NAME}
i2c
)
To your CMakeList.txt.
Step 2: Declare the headers as "C",
extern "C"
{
#include<linux/i2c-dev.h>
#include <i2c/smbus.h>
}
Because libi2c.so is a dynamic library compiled with GCC.
If you do not declare it explicitly, the g++ will generate different function names in the symbol table thus the ld command cannot find any match in the i2c library.
The answer is, you can use the command target_link_libraries() after creating the executable. You have to provide the name of the object and a path to the .so-file (usually found in /usr/lib). In my case, that would be:
target_link_libraries(main, "/usr/lib/aarch64-linux-gnu/libi2c.so")
I am trying to use this C++ library (png++) on Windows, but I unable to compile any program when I use it. Example of Code I am using to test:
#include <png++/png.hpp>
#include <png.h>
int main(){
//anything
}
When I try to compile using g++ -I path/png++ main.cpp -o main, I get
fatal error: png++/png.hpp: No such file or directory
#include <png++/png.hpp>
I understand png++ depends on libpng, I tried adding it as an I- flag, i.e. compile using
g++ -I path/png++ -I path/libpng main.cpp -o main, but it doesn't resolve the issue, png.h is found by the compiler but not png++/png.hpp.
I hope someone will be able to help.
Thanks!
I am trying to get an OpenGL program working on both linux and windows.
Here's my code [file=main.cc]:
#include <iostream>
#include "GL/glew.h"
using namespace std;
int main(int argc, char *argv[]){
cout << "Hello World\n";
return 0;
}
Simple enough. I'm on Linux and using
g++ main.cc -lGL -lGLEW -lSDL2
to compile my program. It works perfectly fine and if I run ./a.out I get a Hello World on my screen.
Then I try to compile it on Linux for Windows using the command
x86_64-w64-mingw32-g++ main.cc -lGL -LGLEW -LSDL2
Then however i get the error:
main.cc:3:21: fatal error: GL/glew.h: No such file or directory
#include "GL/glew.h"
^
compilation terminated.
I've already tried adding the -I/inclulde/path option with paths like /usr/include /usr/include/GL usr/include and the like, yet nothing wants to compile.
The Libraries that I'm using (or planning to) were installed using
#apt install libgl-dev libglew-dev libsdl2-dev
Any help would be very much appreciated (although I feel this is an incredibly easy fix that I'm just too stupid to figure out on my own)
I want to write simple C codes to use the functions in ModemManager 1.4.12 to use some of the functions provided in ModemManager to do modem related functions.
I have added the headers I need:
#include "config.h"
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include <glib.h>
#include <gio/gio.h>
#include <libmm-glib.h>
#include "mmcli.h"
#include "mmcli-common.h"
Compile with gcc -o test test.h
but it complains that glib.h is not found.
When I compile with:
gcc -Wall pkg-config --cflags libnm pkg-config --cflags --libs gio-2.0
it complains that fatal error: libmm-glib.h: No such file or directory
When I use -I to include libmm-glib.h, it complains that ModemManager.h is not found.
Should I keep Adding directories with -I or is there a more proper way of doing it?
Thanks
It is not clear what you want to accomplish...
Do you want to build a separate program that uses libmm-glib to talk to ModemManager via DBus? If so:
/* save as test.c and compile with:
* $ gcc -o test `pkg-config --cflags --libs mm-glib` test.c
*/
#include <libmm-glib.h>
int main (int argc, const char **argv)
{
...
}
Note that pkg-config requesting mm-glib cflags/libs should be enough, as that will pull any additional dependency cflags/libs, like glib/gobject/gio.
But from the looks of your code sample, you're also adding mmcli specific headers... so do you want to extend mmcli with new capabilities? If so, instead of giving custom gcc commands, you should extend the mmcli sources and if you need to add new files in the compilation of mmcli, just modify the Makefile.am under cli/.
I setup SDL2 under C++ CDT Eclipse.
I added the include path "........SDL2-2.0.3\i686-w64-mingw32\include", the library path "........SDL2-2.0.3\i686-w64-mingw32\lib" and added the libraries 1."mingw32" 2."SDL2main" 3."SDL2".
So now, if I add a main.cpp with this content:
#include <SDL.h>
int main(int argc, char* args[])
{
return 0;
}
I can build the project fine, but if I use this:
#include <SDL.h>
int main()
{
return 0;
}
The project can't build and I get this error:
Info: Internal Builder is used for build g++ "-IO:\Eclipse CDT
Workspace\SDL OpenGL Lab\Libraries\SDL2\include\SDL2" -O0 -g3
-Wall -c -fmessage-length=0 -o main.o "..\main.cpp" g++ "-LO:\Eclipse CDT Workspace\SDL OpenGL Lab\Libraries\SDL2\lib" -o
"SDL OpenGL Lab.exe" main.o -lmingw32 -lSDL2main -lSDL2 O:\Eclipse
CDT Workspace\SDL OpenGL
Lab\Libraries\SDL2\lib/libSDL2main.a(SDL_windows_main.o): In function
console_main':
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x86/../src/main/windows/SDL_windows_main.c:140:
undefined reference toSDL_main' collect2.exe: error: ld returned 1
exit status
I simply wonder me why this error is depending on my main method, I want to use the main method I want.
Why this is so, how I can fix this ?
Sorry, you're stuck with it. I also preferred a simpler main, but SDL doesn't support it.
Here's a little more on SDL and main in the Windows world. It doesn't say why you need their version of main -- but you do.
I get "Undefined reference to 'SDL_main'" ...
Make sure that you are declaring main() as:
#include "SDL.h"
int main(int argc, char *argv[])
https://wiki.libsdl.org/FAQWindows
I had the same problem and had to go through a lot of manipulations.
What I have found is the simple line #define SDL_MAIN_HANDLED before calling SDL.h. SDL has his own main that's why, I think.
For example, in my .h files, I write everytime this :
#include <stdio.h>
#include <stdlib.h>
#define SDL_MAIN_HANDLED
#include <SDL.h>
#include <SDL_image.h>
#include <SDL_ttf.h>