not sure if this is an appropriate question...
Im using netbeans, and have started to play about with gtk-3.0.
In Netbeans library manager I have added the path /usr/include/gtk-3.0. I have tried to compile a simple project which uses one of the gtk header files. It will not compile, states header file not found. I have checked the class path is correct and that the header file is in the specified location. But had no joy. (the headerfile I am using is gtkmm.h)
I then tried putting the same path into the include directories list in project properties, and the program compiles fine.
My question therefore is, does adding the path in netbeans library manager not automatically include it for my program? I thought this was the whole point? I am stuck with having to add my paths to each new project I create? I thought putting them into the library manager would make this unnecessary? I thought this was the whole point of library manager?
The simplest way is to create a NetBeans "project with existing sources". In order to begin you'll need a directory with only two files - a Makefile and one simple C++ program (with empty main function). However, the Makefile must know about the gtkmm. The pkg-config tool is your friend (in Unix/Linux environment). I have following gtkmm-related lines in my Makefile:
GTKMM_VERSION := gtkmm-3.0
CFLAGS += ${shell pkg-config --cflags ${GTKMM_VERSION}}
LDLIBS += ${shell pkg-config --libs ${GTKMM_VERSION}}
Then you'll need to create a new project in NetBeans - choose "C/C++ Project with existing sources" and tell the NetBeans where your directory is located. The NetBeans will find the Makefile automatically and will try to run it.
A good idea is to run the make in this directory even before creation a new NetBeans project - to make sure the Makefile does what you want.
Related
I am trying to use SQLCipher within my QT C++ project. I am running a windows machine and I have used steps explained in here (until end of step 5) to generate my sqlite3.h, sqlite3.c, sqlcipher.exe and sqlite3.dll. Hopefully, now I have an executable that works fine but I am trying to make use of SQLCipher within my QT project. I want to add sqlite3.h and sqlite3.dll to my project and use its functions to work with databases. I have copied sqlite3.h and sqlite3.dll from sqlcipher-master into my project. My .pro file looks like this:
HEADERS +=\
sqlcipher/sqlite3.h \
myOtherHeaderFiles.\
QMAKE_CXXFLAGS += -DSQLITE_OS_WIN=1 -DSQLITE_HAS_CODEC -DSQLITE_TEMP_STORE=2 -ldl -lpthread
LIBS+="path\to\project\sqlite3.dll"
When I try to build my project no compiling error occurs but when I try to run it I get:
11:55:15: Starting path\to\project\build-project-Desktop_Qt_5_14_1_MinGW_32_bit-Debug\project.exe ...
11:55:15: The program has unexpectedly finished.
11:55:15: The process was ended forcefully.
11:55:15: path\to\project\build-project-Desktop_Qt_5_14_1_MinGW_32_bit-Debug\project\build-project-Desktop_Qt_5_14_1_MinGW_32_bit-Debug\project.exe crashed.
Do I miss something important? Do I copy the wrong files or is there anything more to add to my project before building it? if you have had the experience of using SQLCipher in a QT+mingw project please leave a comment or guide me through.
I'm on a Xubuntu machine. I've downloaded and compiled the source, did the make install.
I'm trying to create a simple wxFrame class, but when I include <wx-3.0/wx/frame.h>, it says Can't resolve type wxFrame. When I look inside frame.h, it includes a reference to <wx/toplevel.h>. Both frame.h and toplevel.h are in the same folder. Why does the compilation place the include files all in the same folder, but the paths to the files are different?
I am using CLion IDE and the include/lib paths are set by cmake's FIND_PACKAGE().
#ShrimpCrackers,
It is generally advisable to start you project by copying one of the sample code into you project and then set you project properties to the output of wx-config --cxxflags and wx-config --libs.
So what you should do is to copy the wxWidgets/samples/minimal/minimal.cpp over to the directory where you project is, fix the project properties and recompile.
BTW, you don't have to do make install. You might want to compile debug and release versions of the library on one machine which defeats the purpose of installing. You just use the compiled version of the library
I need to ship a product with shared libraries (Ubuntu) in a folder I've created ('shared') within the project directory--i.e., shared libraries that are not in /usr/lib, /usr/local/lib, etc. To this end I've done this in the .pro file, i.e.
LIBS += -Lshared/gsl -lgsl -lgsl_cblas
NB the executable is in the same directory asy the 'shared' folder. Everything works when I launch the program in debug mode from QtCreator. In addition the program fails to launch if I remove or rename the libs in 'shared', and also I've verified that the app is not finding these libraries anywhere else. But when I launch from the command line, I get
error while loading shared libraries: libgslcblas.so.0: cannot open
shared object file: No such file or directory
What's going on?
EDIT: The solution is a variation on lionbest's below, as developed in the comments. For some reason, it turns out that on my platform qmake/QMAKE_FLAGS only allows a specific format for linker options, and not the one you find googling around for other instances where people have worked with QMAKE_FLAGS. Namely,
QMAKE_FLAGS += "-Wl,-rpath,\'\$$ORIGIN/shared/gsl\'"
QMAKE_LFLAGS_RPATH=
Specifically, the problem was that the parser (or linker) would not accept -rpath=..., despite the fact that this seems to work for everyone else. Ubuntu 12.04, gcc 4.6.3, Qt 4.8.0, QtCreator 2.4.1 "based on Qt 4.7.4". Hope this experience can save someone else the same frustration.
Start a program with environmental variable LD_LIBRARY_PATH=shared/gsl or add a RPATH to linker settings:
LIBS += -Wl,-rpath=shared/gsl
If you want to make shortcut for your application, most distribution (based on Gnome, KDE, LXDE and XFCE) use a .desktop file. QtCreator probably generated one for you. You need to edit it or generate it, and put to $HOME/.local/applications or /usr/share/applications/ during installation. In desktop file you could add envirometal varible and starting directory as follow:
Exec=/usr/bin/env LD_LIBRARY_PATH=/<path_to_libs>/ /<path>/app -extra_options
If you need to run your application in specific directory add line:
Path=/<path_to_your_application_working_dir>
You can use ${} inside path.
I currently have a project, written in C++, it uses multiple libraries, including an sqlite and a wxWidgets library, it has a Graphical User Interface, made with Interface Builder.
This project was made with Code::Blocks.
What I now want to do, is import this whole project into XCode to make an .app file. I know about linking and search paths and all that (learned how to do that with a Command Line Project), but other then that, I don't really know where to start. I have searched a lot of forums but it's driving me crazy.
Can anybody help me out with a step-by-step of some sort?
Thanks!
Steps taken
wx-config --cppflags
wx-config --libs
Opening a new xcode project (cocoa)
Pasting the code written (all the classes, and the interface built)
Organizing the header search paths (including the output of libs)
Organizing the linking
Organizing the GCC other flags (including the output of cppflags here)
after that it worked.
Wanted to try using qt creator (coming from eclipse cdt) and I'm trying to get my project to build. Unfortunately, qmake is adding -L/usr/lib to the linker options by itself, making it link to the wrong version of a library, and I can't figure out how to remove it.
I've tried doing "LIBS = " in the project file, as well as "LIBS -= -L/usr/lib", but it seems to be adding the option after it reads the settings from the project file. Anyone know if there's a conf file somewhere (e.g. mkspecs directory) where I can comment this out? Thanks.
It comes from qmake itself. It puts qt_libspath into link flags. It can be changed by either configuring and compiling Qt with a different directory prefix, or by modifying the qmake binary itself.
An easy solution for you could be to create a filesystem-level link to the correct library version with a different name. That is, if you have /usr/lib/libfoo.so and myfoo/lib/libfoo.so, create a link libmyfoo.so -> myfoo/lib/libfoo.so and link with -lmyfoo instead of -lfoo.