Can't link ncurses with Qt - c++

I included <ncurses.h> , but can't link ncurses's libs in .pro file. I'm trying like this:
LIBS += -L"/usr/lib/" -libncurses.a
I tried different variations of linking (with/without file_type, different variations of directory), but it didn't help. Then I decided to link via console using:
g++ -lncurses main.cpp snake.cpp
Tried to put -lncurses in different places of command.
It gives me an error:
undefined reference to move(); (ncurses's func)
And it doesn't want to compile C++11 features, like std::list.empalce_front();. The reason I'm asking for help for second problem in the same question, is that if would able compile only via console, so i won't be able to use C++11 features, but i want to!
P.S. Of course, the main problem is with linking ncurses's libs

http://www.lucidarme.me/?p=3961 Here You can find a solution. Main reason is You incorrectly set project:
LIBS += -lncurses
Check a link I sent You. Everything is there clear.

Related

Problems with including custom c++ library in Visual Studio Code

I was trying to include the GMP library, which was simply the code below(I did nothing else):
#include <gmpxx.h>
However, when I tried to compile the code, the following error from g++ compiler occured:
myCode.cpp:3:10: fatal error: gmpxx.h: No such file or directory
#include <gmpxx.h>
^~~~~~~~~~~~~~~~~~~~~~
I have tried everything I searched online, putting the GMP lib here and there, adding INFINITE includepaths in c_cpp_properties.json, still, it keeps showing the message, although, I can find the file through "Go to Definition" option.
Is there any known solution to this?
It's not enough to configure VS Code includes, you need to pass those options to the compiler as well.
You don't mention your platform at all, so I'm going to use an example from my personal machine, a Macbook Pro with the fmt library.
When compiling with the fmt library, I have to provide three more options to the compiler.
-I/usr/local/include // Tells the compiler where to look for extra includes
-L/usr/local/lib // Tells the compiler where to look for extra libraries
-lfmt // fmt-specific command to use fmt library
So the full command ends up looking like this:
g++ -Wall -std=c++17 -I/user/local/include -L/usr/local/lib -lfmt main.cpp
I need all three options because fmt is installed in a non-standard location that the compiler doesn't check by default. According to the documentation, you can get away with just -lgmp and -lgmpxx if you installed the library in a standard location (happens by default with *nix and a package manager, I imagine).
If you use build tasks in VS Code, this can be set up and automated for you.

How to use libsensors in QT application?

I am trying to make a simple CPU temp program in QT for Linux, but I cannot get libsensors to work with my project. As soon as I include the sensors/sensors.h and try to call int err = sensors_init(NULL); the compiler throws an error undefined reference to 'sensors_init'. I believe this is a linking issue, but I cannot solve it.
Edit:
I can fix the problem if I manually compile outside of QT creator with g++ -o main main.cpp -lsensors.
Now my question is how do I pass the -lsensors parameter to the g++ compiler in the QT creator. I am using qmake.
The solution is to add QMAKE_LIBDIR_FLAGS += -lsensors to the .pro file.

Library not linking/including properly

Alright, I realize that this might seem like a duplicate, but I've tried most variations and attempts via' searched posts, and I'm still coming up with nothing. Here's the issue: I am working with an open-source C library called libxls that is used for reading .xls files (aptly named project.. :) ). The code I'm using is straight off their website, essentially just a beginning toy example to make sure I can access the libraries:Link to their website with the source
#include <stdio.h>
#include "libxls/xls.h"
int main(){
xlsWorkBook* pWB;
pWB = xls_open("Book1.xls", "iso-8859-15//TRANSLIT");
return 0;
}
That's it. Now, the syntax of that is fine. I know for a fact through the nm command that xls_open is indeed available as a function in the .a library, so that's not a problem. in my directory I have the following files (pardon the redundant naming, I was just trying to force it to work real quick):
Book1.xls
libxlsreader.a
libxlsReader.c
libxlsreader.so
Although I don't THINK I need the .so file here since I've tried dynamically linking to where that lives, figured it wasn't a bad plan to try. Alright, so, on the include line, I keep getting the common:
libxlsreader.c:3:37: fatal erro: libxls/xls.h: No such file or directory
Ok fine, so I probably linked in the library wrong, take a look at my compile line arguments:
gcc -o libxlsWrapper libxlsReader.c -L /usr/local/lib/ -lxlsreader -lpthread
huh, well.. that certainly LOOKS right, /usr/local/lib/ is where the library created itself with all of it's .so files, and the .a one in my PWD. Now, I'm a java developer by trade, so I might be missing something blaringly obvious, but for the life of me I can't determine what it is. it certainly seems ok to me.
I'm using GCC (ubuntu/Linaro 4.7.3-lubunutul) 4.7.3 on Linux Mint 15 KDE 32-bit.
If you'd like to reproduce the library for your own testing or problem solving, it can be obtained from
I don't recommend recreating it on windows, I tried for a couple hours yesterday and gave up, so just do the regular ./configure -> make -> make install and that should produce the appropriate libraries for you.
Thanks!
-Will
edit #1: here are some of the other linking attempts I've tried, all with the identical result.
gcc -o libxlsWrapper libxlsReader.c -L. -lxlsreader -I.
gcc -o libxlsWrapper libxlsReader.c -L. -lxlsreader -lpthread
gcc -o libxlsWrapper libxlsReader.c -L. -lxlsreader.so
I also tried a bunch with g++ instead of gcc (throwing darts, I know), same result.
Please do a find your_folder -type f -iname xls.h and then use a gcc -I /the_path to include the path for xls.h. Because the problem you have is that gcc could not locate the header file xls.h.

Trouble using Botan with Qt

I am using Qt and I am trying to use Botan. Everything seemed to go well, but when I go:
Botan::BigInt myInt;
In my constructor it works fine, but on the other hand if I go:
Botan::AutoSeeded_RNG rng;
It throws undefined errors:
C:\Users\Stevie\Desktop\asfsdf-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\debug\mainwindow.o:-1: In function `AutoSeeded_RNG':
C:\Users\Stevie\Desktop\asfsdf-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\..\..\..\botan\include\botan\auto_rng.h:40: error: undefined reference to `_imp___ZN5Botan23Global_State_Management12global_stateEv'
C:\Users\Stevie\Desktop\asfsdf-build-desktop-Qt_4_8_1_for_Desktop_-_MinGW__Qt_SDK__Debug\..\..\..\..\botan\include\botan\auto_rng.h:40: error: undefined reference to `_imp___ZN5Botan13Library_State10global_rngEv'
:-1: error: collect2: ld returned 1 exit status
I have no idea why it would work with a BigInt but not the AutoSeeded_RNG, but here are my exact steps:
Compiled the Botan source included in the Qt Creator source at "src/libs/3rdparty/botan/"
I installed Botan using the Windows Installer (1.10) from their website.
I took the libBotan.a, libBotand.a, botan.dll, and Botand.dll and put them in the location where I installed Botan (C:\botan). I overwrote any of those files that already existed.
I then created a new Qt project, and inside of the .pro file I added the following lines:
INCLUDEPATH += "C:/botan/include"
LIBS += "C:/botan/libBotan.a"
Next, I go into my "mainwindow.cpp", and add:
#include <botan/botan.h>
Everything compiles up to here successfully.
I now add this to my constructor:
Botan::AutoSeeded_RNG rng;
Now the above errors are thrown, and cannot be ran. If I replace the "AutoSeeded_RNG" with "BigInt", then it compiles perfectly.
Thanks for any help, Hetelek.
The statement to link against the Botan library looks strange to me. Normally, you specify library directories using the -L switch and add a library with the -l switch, i.e you should use
LIBS += -L"C:\botan" -lBotan
Note that the prefix and suffix of the library are not specified in lbotan. The linker will automatically look for a libbotan.a or botan.dll, depending on your environment.
Botan is also part of QtCreator. Maybe you should have a look at their repository. You can find .pri and .pro files there and probably only need to copy them. They also have written a .qbs driver for the new Qt build system.
Edit: I just compiled Botan from the QtCreator sources, as you also mentioned in your post. I then copied all the generated libraries in my own directory and I also used the botan.h which was shipped with QtCreator. On Linux I had to add
LIBS += -L"/dir/into/which/i/copied/botan/dlls" -LBotan -ldl
to the qmake .pro file. Note the additional -ldl otherwise I got undefined references to dlym, dlerror etc. I could compile a simple example with Botan::AutoSeeded_RNG without problems.

GCC debugger stack trace displays wrong file name and line number

I am trying to port a fairly large C++ project to using g++ 4.0 on Mac OS X. My project compiles without errors, but I can't get GDB to work properly. When I look at the stack by typing "bt" on the GDB command line, all file names and line numbers displayed are wrong.
For example, according to the GDB stack trace, my main() function is supposed to be in stdexcept from the Mac OS X SDK, which does not make any sense.
What could cause GDB to malfunction so badly? I've already checked for #line and #file statements in my code and made sure that the code only has unix line endings. I've also cleaned and rebuilt the project. I've also tried debugging a Hello World project and that one did not have the same problem.
Could the problem have to do with one of the third party libraries I am linking and the way those are compiled? Or is it something completely different?
Here are two exemplary calls to gcc and ld as executed by Xcode. AFAIK all cpp-files in my project are compiled and linked with the same parameters.
/Developer/usr/bin/gcc-4.0 -x c++
-arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -fpermissive -Wreturn-type -Wunused-variable -DNO_BASS_SOUND -D_DEBUG -DXCODE -D__WXMAC__ -isysroot /Developer/SDKs/MacOSX10.5.sdk
-mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.4 -gdwarf-2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -c "/Users/adriangrigore/Documents/Gemsweeper
Mac/TSDLGameBase.cpp" -o
"/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Gemsweeper
Mac.build/Debug/Gemsweeper
Mac.build/Objects-normal/i386/TSDLGameBase.o"
/Developer/usr/bin/g++-4.0 -arch i386
-isysroot /Developer/SDKs/MacOSX10.5.sdk
"-L/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Debug"
-L/Developer/SDKs/MacOSX10.5.sdk/usr/local/lib
-L/opt/local/lib "-F/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Debug"
-F/Users/adriangrigore/Library/Frameworks
-F/Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks
-filelist "/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Gemsweeper
Mac.build/Debug/Gemsweeper
Mac.build/Objects-normal/i386/Gemsweeper
Mac.LinkFileList"
-mmacosx-version-min=10.4 /opt/local/lib/libboost_program_options-mt.a
/opt/local/lib/libboost_filesystem-mt.a
/opt/local/lib/libboost_serialization-mt.a
/opt/local/lib/libboost_system-mt.a
/opt/local/lib/libboost_thread-mt.a
"/Users/adriangrigore/Documents/Gemsweeper
Mac/3rd
party/FreeImage/Dist/libfreeimage.a"
"/Users/adriangrigore/Documents/Gemsweeper
Mac/3rd
party/cpuinfo-1.0/libcpuinfo.a"
-L/usr/local/lib -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL -lwx_macd_richtext-2.8 -lwx_macd_aui-2.8 -lwx_macd_xrc-2.8 -lwx_macd_qa-2.8 -lwx_macd_html-2.8 -lwx_macd_adv-2.8 -lwx_macd_core-2.8 -lwx_base_carbond_xml-2.8 -lwx_base_carbond_net-2.8 -lwx_base_carbond-2.8 -framework SDL -framework Cocoa -o "/Users/adriangrigore/Documents/Gemsweeper
Mac/build/Debug/Gemsweeper
Mac.app/Contents/MacOS/Gemsweeper Mac"
Please note that I have already asked a similar question regarding the Xcode debugger here, but I am reposting since I just learned that this is in fact not Xcode's fault, but a problem with GCC / ld / GDB.
Edit: My project makes use of the following third-party libraries: SDL, Boost, wxWidgets. I am not sure if this matters for this problem, but I just wanted to mention it just in case it does.
I've tried compiling an Xcode SDL project template and did not experience the same problem, so it must be due to something special in my project.
Second Edit: As I just found out, I made a mistake while searching files with the string "This is an automatically generated". I just found several dozen files with the same string, all belonging to FreeImage, one of the third party libraries I am using. So, the problem seems to be related to FreeImage, but I am not still not sure how to proceed.
I got those symptoms, when my gdb version didn't match my g++ version.
Try to get the newest gdb.
Your cpp files certainly have debug symbols in them (the -gdwarf-2 option).
Do you use a separate dSYM file for the debug symbols? Or are they inside the object files. I would first try to use DWARF in dSYM files and see if that helps (or vice versa)
The third party libraries appear to be release builds though (unless you renamed them yourself of course) e.g. I know for sure boost uses the -d monniker in the library names to denote debug libraries (e.g. libboost_filesystem-mt-d.a).
Now, this shouldn't really pose a problem, it should just mean you can't step into the calls made to third party libraries. (at least not make any sense of it when you do ;) But since you have problems, it might be worth a try to link with debug versions of those libraries...
Are you compiling with optimization on? I've found that O2 or higher messes with the symbols quite a bit, making gdb and core files pretty much useless.
Also, be sure you are compiling with the -g option.
Can it be that you are using SDL? SDL redefines main so your main will be named SDL_main and that the SDL parts might be heavy optimized so down there you'll have problem getting good gdb output.
...just a thought
Read this
For a test, you could check if addr2line gives you expected values. If so, this would indicate that there's nothing wrong with the ELF generated by your compile/link parameters and casts all suspicion on GDB. If not, then suspicion is still on both the tools and the ELF file.
I've tried compiling an XCode SDL
project template and did not
experience the same problem, so it
must be due to something special in my
project.
Correct. Your project settings are the thing that is different.
You will need to disable the debug optimizations in the Xcode project settings for the debug build. Xcode unfortunately makes GDB jump to weird lines (out of order) when you would expect it to move sequentially.
Go to your project settings. Set the following
1) Instruction Scheduling = None
2) Optimization Level = None [-O0]
3) ZERO_LINK = None
Your problems should go after after doing this.
Here is the project settings screen that you need to change the settings on:
From your flags the debug information should be in the object files.
Does your project settings build the executable in one location then move the final executable to another location when completed? If this is the case then gdb may not be finding the objectects files and thus not correctly retrieving the debug information from the object files.
Just a guess.
I encountered this several years ago when transitioning from the Codewarrior compilers to Xcode. I believe the way to get around this is to put the flag "-fno-inline-functions" in Other C Flags (for Dev only).
This problem was more pronounced on the PowerPC architecture for us.
What about if you remove the "-fvisibility-inlines-hidden" and "-mfix-and-continue" flags?
I've never had the "fix and continue" feature work properly for me.
WxWidgets do also define their own main if you use their IMPLEMENT_APP() macro
From here
As in all programs there must be a "main" function. Under wxWidgets main is implemented using this macro, which creates an application instance and starts the program.
IMPLEMENT_APP(MyApp)
See my answer here
I have now downloaded and compiled the FreeImage sources and yes, the file b44ExpLogTable.cpp is compiled into libfreeimage.a. The problem looks like the script gensrclist.sh just collects all .cpp files without skipping the one with a main in. That script generates a file named Makefile.srcs but one is already supplied. (running it on my Leopard failed, some problem with sh - it worked if I changed sh to bash)
Before you have changed anything this gives an a.out
c++ libfreeimage.a
The file Makefile.srcs has already been created so you should be able to remove the file b44ExpLogTable.cpp from it. Then do
make -f Makefile.osx clean
make -f Makefile.osx
When this is done the above c++ libfreeimage.a should give the following error
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I have a new thing you can try.
Just before your own main you can write
#ifdef main
# error main is defined
#endif
int main(int argc, char *argv[]) {
this should give an error if you have some header that redefines main.
If you define an own you might get an warning where a previous definition was made
#define main foo
int main(int argc, char *argv[]) {
You can also try to undef just before your main
#undef main
int main(int argc, char *argv[]) {