I am new to C++ and plugin development. I am working with/for Unix and for the Firefox browser. So here we go:
I have a plugin which uses some classes from a own library. The problem is: it kills my browser asap. I cant even start my browser as soon as MyPlugin.so is in the plugin folder of the Firefox. The library is build and doesn't kill a desktop application that uses it.
My guess is that I failed at linking my library with CMake or forgot to include some stuff from FireBreath. So here are the two things I assume are wrong, maybe someone can help me out.
1) (wrong?) linking with Cmake:
I added some of these at the end of the CMakeLists.txt of my project. The paths are where the library is.
add_definitions(-L${CMAKE_CURRENT_SOURCE_DIR}/../../../lib/bin)
add_definitions(-I${CMAKE_CURRENT_SOURCE_DIR}/../../../lib/src)
add_definitions(-lcoala64) [name of the library]
add_definitions(-Wl,-rpath=${CMAKE_CURRENT_SOURCE_DIR}/../../../lib/bin)
add_definitions(-pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0)
And used the prepmake.sh to generate my build files. Then I followed up with adding flags manually (because I dont know a better solution) to the in the /buid/projects/MyPlugin/CMakeFiles/MyPlugin.dir/link.txt
-L/home/username/swp/dev/lib/bin
-I/home/username/swp/dev/lib/src
-lcoala64 -Wl,-rpath=/home/username/swp/dev/lib/bin
Afterwards I could build the plugin. It builds, so one could assume I have linked correctly. But said crashes appear as soon as I want to use it.
2) Do I use the library wrong?
I include like this in MyPluginAPI.h:
#include <string>
#include <sstream>
#include <boost/weak_ptr.hpp>
#include <boost/smart_ptr.hpp>
#include "JSAPIAuto.h"
#include "BrowserHost.h"
#include "X11/X11KryptoKoala.h"
//Include from my own library:
#include "../../../lib/src/Key.hpp"
As soon as I add the following line to MyPlugin.cpp I get the mentioned crashes while the same line works without a problem in the desktop application that uses the same library:
Key key(password_);
Now I hope this isn't a too big wall of text and someone is willing to investigate and answer to me.
You shouldn't use add_definitions() in that way. CMake allows to differentiate your directives in different categories, so that they only go in the necessary command line. You should use:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")
include_directories(/usr/include/gtk-2.0
/usr/include/cairo
etc. etc.
)
add_library(the_name_of_your_target gtk-x11-2.0 gdk-x11-2.0 ETC. ETC.)
link_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../../lib/bin)
Furthermore, there are FindPackage functionalities that can help you setting automatically variables containing the name of your libraries, their directories, their include path.
Most information can be found here and here
Then: What is then prepmake.sh? Are you running cmake at all? Can you use cmake-gui, and then select one canonical build system, like make or ninja?
Finally: It could be that you have a crash because your library are not in your library path. I assume you are under linux, here are some ideas: LD_LIBRARY_PATH vs LIBRARY_PATH and LD_LIBRARY_PATH
Related
Background
I'm currently dabbling in the world of game programming, and following an online guide from bell0bytes. Right now I'm working on this tutorial: https://bell0bytes.eu/lua-and-game-settings/
Therein, the writer suggests "Avoiding DLL Hell" by simply placing the Lua DLL in the local project directory, but that's sloppy, IMO. I've recently started a career as a software engineer (primarily C++) and my team uses CMake and VS to manage our product. I'm confident in my C++ skills and in using VS, but I'm far from mastering CMake, and I'm trying to improve my skills across the board by maintaining a similar dev environment to my work environment for this personal project, meaning that putting the DLL into my driver/project directory and calling it a day isn't sufficient here.
So indeed, we're off to DLL Hell.
System & Versioning Information
OS: Microsoft Windows 10 Pro (10.0.18362 Build 18362)
Sys: x64 Desktop
VS: Microsoft Visual Studio Community 2019 (16.5.4)
CMake: CMake (3.17.1) (Windows x64 Executables for Attempt 1, Source Code and Makefiles for Attempt 2)
Lua: Lua (5.3.5)
Relevant Directories: ../dev/<myprojectdirectory>/, ../dev/resources/
Goal
I want to write the line #include <lua.h> or #include <lua.hpp> or something to that effect in my driver (.cpp / WinMain file) such that I can access the data structures and methods within that Lua header, with the stipulation that this dependency needs to be managed by CMake external to my project, meaning no Lua files end up copied into my working project directory (i.e. Not in here: ../dev/<myprojectdirectory>/ , or any of its subdirectories (excluding maybe <myprojectdirectory>/build/ (CMake generated bin) directory... assuming someone can explain why that's acceptable, from a professional / software engineering standpoint)).
Attempt 1
Originally I grabbed the x64 binaries for Lua from here: http://luabinaries.sourceforge.net/download.html
and after extracting the compressed content, I put the DLL here: ../dev/resources/Lua/lua53.dll
which I'm good with. A solution in which CMake grabs that DLL from my resources directory, and links it into such that IntelliSense can actually find the lua header, such that I can write the following code (from the guide I referenced earlier):
// BEGIN This is my driver
#include <windows.h>
#include <lua.hpp>
#pragma comment(lib, "liblua53.a") // Fairly sure I wont need this line if Lua is linked correctly
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
lua_State *state = luaL_newstate();
lua_close(state);
return 0;
}
// END my driver
and successfully compile my bare bones project, would be perfect.
Attempt 2:
Alternatively a Statically linked solution that works something like the following would be fine too:
I searched stackoverflow and found this, which made me hopeful at first:
Download and build Lua with modern CMake
After adjusting the following code, provided by the OP from the above thread:
cmake_minimum_required(VERSION 3.10)
include(ExternalProject)
ExternalProject_Add(lua
URL "https://www.lua.org/ftp/lua-5.3.5.tar.gz"
CONFIGURE_COMMAND ""
BUILD_COMMAND make generic
BUILD_ALWAYS true
BUILD_IN_SOURCE true
INSTALL_COMMAND ""
)
add_library(liblua STATIC IMPORTED)
ExternalProject_Get_property(lua SOURCE_DIR)
message("liblua will be found at \'${SOURCE_DIR}/src\'")
to my needs, my top level, bare bones CMakeLists.txt file ../dev/<myprojectdirectory>/CMakeLists.txt looks like this:
# BEGIN This is my CMakeLists.txt file
cmake_minimum_required(VERSION 3.2.3)
project(<myprojectname>)
cmake_minimum_required(VERSION 3.10)
include(ExternalProject)
ExternalProject_Add(lua
URL "https://www.lua.org/ftp/lua-5.3.5.tar.gz"
CONFIGURE_COMMAND ""
BUILD_COMMAND make generic
BUILD_ALWAYS true
BUILD_IN_SOURCE true
INSTALL_COMMAND ""
)
add_library(liblua STATIC IMPORTED)
ExternalProject_Get_property(lua SOURCE_DIR)
message("liblua will be found at \'${SOURCE_DIR}/src\'")
add_executable(${PROJECT_NAME} WIN32 <projectsource>)
# END my CMakeLists.txt file
I configured CMake(no errors/warnings) + generated, and finally opened the newly created VS project, thinking that I could #include <lua.h> / #include <lua.hpp> (statically, I think?) with no further trouble, but that didn't work, VS/IntelliSense didn't find the header.
Closing Remarks:
Eventually, I couldn't find anything else to try, or any more clues (I looked through documentation for Lua and CMake on their respective websites for instructions as well). So, stuck in Hell for the first time in quite a while, I decided it was about time I start an account with stack, and query the community.
The solution I'm looking for (of course) gets me to the point where I can use Lua cleanly (preferably dynamically, but statically would be Ok, without manually adjusting any project properties from VS) (If possible please include full code/files for CMakeLists.txt, or C++ drivers, not just snippets, with explanations).
Finally (and importantly), I'm much more interested in an explanation surrounding DLLs, static libraries, CMake, correctly establishing VS project dependencies & linking via CMake, and hopefully, an explanation of where/why I fell short on these two attempts.
Thanks!
Other Stack Exchange Resources I've Reviewed In My Quest For the Answer
Building 64bit application with makefiles using cmake-gui
How do I set the path to a DLL file in Visual Studio?
How to use external DLLs in CMake project
Ideal way to include headers from a DLL?
Unable to find Lua headers with find_package in cmake
Download and build Lua with modern CMake
~ I'm not stupid, but you're welcome to explain it to me like I'm 3. I want to understand, not just get the answer.
Is there a way to create an alias for #included resources within one of the directives of CMakeLists.txt?
I am looking for a way to define something in the CMakeLists.txt so any occurrence of global resource like
#include <some/global/dependency/file.h>
will be aliased to the right resource, so CMake will also look for it in the following locations
#include "../file/is/here/file.h"
#include "file.h"
#include <alias.h>
Why?
I am working on a very complex project with containerized build system. Means, lot of manual work should be done to make the project play well in any IDE. Actually, there are lot of sub projects within the main project that being individually compiled with lot of dedicate configurations.
I am using CLion as my IDE. CLion support CMake out of the box, but my project is not using cmake :) I created custom CMakeLists.txt file by simply including lot of folders (with header files) by using include_directories() directive, and for now it works very well. It able to recognize symbols/navigation/macros generation and build a nice index of the included files.
But I have this problem where, in some files CLion not able to recognize the file path because the #include refers to global (prebuilt / containerized) path/file which does not exist on my real file system, but generally, any such resource exist in the project under different path. So I wonder is there a way to just instruct CMake to do the following:
IF asked to #include something from XXX path
THEN first look for it under YYY path or ZZZ path etc'...
if the resource not found in step 2 above, look for it under XXX path
I will appreciate if you can help me to improve the question and title by editing it with better terminology etc'...
CMake by itself doesn't provide a compiler, it is even not a build tool. So, if a compiler cannot replace include directories "on fly", CMake cannot do so.
If you are allowed to copy headers - copy them in proper location, so include_directories() will work.
If you are allowed to copy and modify sources, you may copy them into the new location and run scanner on them, which modifies #include directives.
Otherwise you are out of luck.
I'm using Atmel Studio 6.1.2 SP2. I'm setting up CppUTest for our embedded system project.
I created a static CPP library for the CppUTest Framework which copiled successfuly after a small change. Now I'm including this library to a test project. A C++ application project.
The issue I'm facing now is that even though the intellisense is auto completing my include, that means that it sees where the library is, I get "No chuch file or directory" error when compiling.
In GccApplication1.cpp I have this:
#include <avr32/io.h>
#include <CommandLineTestRunner.h>
int main(int ac, const char** av)
{
/* These checks are here to make sure assertions outside test runs don't crash */
CHECK(true);
LONGS_EQUAL(1, 1);
return CommandLineTestRunner::RunAllTests(ac, av);
}
And the error is that it can't find the CommandLineTestRunner.h. I tried with "" and <> but it doesn't see it.
Any ideas?
For more information. I'm following the steps from Atmel, here is the tutorial:
Adding the library only tells the linker that the file is available to be linked with the rest of your object code. What appears to be missing is telling the compiler where it can find the header files for the library. If you add the library path to your include list you should be good to go.
The "No such file or directory" error is a preprocessor error. It is telling you that the include file cannot be found in the include file path. Your IDE will have a way to specify the include path.
If you are using make, then you will want to use the -I option.
If you are using CppUTest's MakeFileWorker.mk, you will want to add define an environment variable, CPPUTEST_HOME, that specifies the directory where you installed CppUTest.
I hope that helps.
Hello
I'm trying to write some tool using code::blocks, wxWidgets and libxml2 on Windows platform.
Things I've done:
copied libxml2.a, libxml2.dll.a and
other libs to MinGW lib/ folder
Wrote some headers like this in my
source file:
#include <libxml/xmlmemory.h>
#include <libxml/parser.h>
Added -lxml2 to linker
And now, when I'm trying to build this project I'm getting this error:
error: libxml/xmlmemory.h: No such file or directory
Anyone here experienced this error?
I believe that I misconfigured something but don't really know what.
Thanks for your ideas.
In general, it's better to not move things into the mingw directories, but to leave them in their own directories, and add search paths to the project properties so it knows where to look for them.
If you go into your project properties in Code::Blocks, hit the Project build options button, then inside the Linker Settings tab, add the two libraries you're linking against. Then In the Search directories tab, add the /include to compiler search locations, and optionally, add the /lib directory to Linker locations (This isn't necessary if you gave the full path to the .a in the linker settings.
Ok, I found the solution!
<libxml2/libxml/parser.h>
works perfectly
I'm wondering how i can make a portable build system (step-by-step), i currently use cmake because it was easy to set up in the first place, with only one arch target, but now that i have to package the library I'm developing I'm wondering how is the best way to make it portable for arch I'm testing.
I know I need a config.h to define things depending on the arch but I don't know how automatic this can be.
Any other way to have a build system are warmly welcome!
You can just use CMake, it's pretty straightforward.
You need these things:
First, means to find out the configuration specifics. For example, if you know that some function is named differently on some platform, you can use TRY_COMPILE to discover that:
TRY_COMPILE(HAVE_ALTERNATIVE_FUNC
${CMAKE_BINARY_DIR}
${CMAKE_SOURCE_DIR}/alternative_function_test.cpp
CMAKE_FLAGS -DINCLUDE_DIRECTORIES=xxx
)
where alternative_function_test.cpp is a file in your source directory that compiles only with the alternative definition.
This will define variable HAVE_ALTERNATIVE_FUNC if the compile succeeds.
Second, you need to make this definition affect your sources. Either you can add it to compile flags
IF(HAVE_TR1_RANDOM)
ADD_DEFINITIONS(-DHAVE_TR1_RANDOM)
ENDIF(HAVE_TR1_RANDOM)
or you can make a config.h file. Create config.h.in with the following line
#cmakedefine HAVE_ALTERNATIVE_FUNCS
and create a config.h file by this line in CMakeLists.txt (see CONFIGURE_FILE)
CONFIGURE_FILE(config.h.in config.h #ONLY)
the #cmakedefine will be translated to #define or #undef depending on the CMake variable.
BTW, for testing edianness, see this mail
I have been using the GNU autoconf/automake toolchain which has worked well for me so far. I am only really focussed on Linux/x86 (and 64bit) and the Mac, which is important if you are building on a PowerPC, due to endian issues.
With autoconf you can check the host platform with the macro:
AC_CANONICAL_HOST
And check the endianness using:
AC_C_BIGENDIAN
Autoconf will then add definitions to config.h which you can use in your code.
I am not certain (have never tried) how well the GNU autotools work on Windows, so if Windows is one of your targets then you may be better off finding similar functionality with your existing cmake build system.
For a good primer on the autotools, have a look here:
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool