When I try to debug my core-dump via gdb either in Qt or directly from terminal, it gives me bunches of warnings like below. Therefore my backtrace is not working properly.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
warning: Could not load shared library symbols for ).
Do you need "set solib-search-path" or "set sysroot"?
Is this because my executable built without debugging symbols or is the problem about glibc? Do you have any solution to fix this?
Is this because my executable built without debugging symbols or is the problem about glibc?
This has nothing to do with your executable.
GDB needs a version of libthread_db.so.1 that matches your libpthread.so.0, and is not finding such version.
Probable causes (from most to least probable):
You have stripped libpthread.so.0 (don't do that).
You've upgraded your glibc, but the upgrade was incomplete and did not update libthead_db.so.1
You are using some kind of cross-compilation environment, and really do need to set solib-search-path or set libthread-db-search-path such that GDB can find a matching libthread_db.so.1
You can see which versions of libthread_db GDB is trying with set debug libthread-db 1.
Related
I recently started working with Qt. I was trying some simple widgets. It was working as intended with no errors and suddenly Qt doesn't work anymore. I did not change any configuration/settings. I restarted my computer and I started to get the following error. I have no idea how to fix them.
Error (when trying to open an already existing project):
/Qt/5.9.5/gcc_64/mkspecs/features/qmake_use.prf(6): 'take_first' is not a recognized replace function.
Project ERROR: Library '' is not defined.
Warnings while parsing QML type information of Qt/5.9.5/gcc_64/qml:
/Qt/5.9.5/gcc_64/qml/builtins.qmltypes:1:24: Reading only version 1.1 parts.
/Qt/5.9.5/gcc_64/qml/builtins.qmltypes:10:5: Expected only Component and ModuleApi object definitions.
/Qt/5.9.5/gcc_64/mkspecs/features/qmake_use.prf(6): 'take_first' is not a recognized replace function.
Project ERROR: Library '' is not defined.
/Qt/5.9.5/gcc_64/mkspecs/features/toolchain.prf(69): system(execute) requires one or two arguments.
Project ERROR: Cannot run compiler 'g++'. Output:
===================
===================
Error (when trying to create a new project)
Maybe you forgot to setup the environment?
Error while parsing file /workspace/testQt/testQt.pro. Giving up.
/Qt/5.9.5/gcc_64/mkspecs/features/toolchain.prf(69): system(execute) requires one or two arguments.
Project ERROR: Cannot run compiler 'g++'. Output:
===================
===================
Other details:
Qt version: Qt 5.9.5(gcc_64)
Compilier: GCC 7.3.0
OS: Ubuntu 16.04.4 LTS
PS: I had this same error two days back. Reinstalling Qt fixed it but not anymore.
There is no problem with g++. I complied a code with the same complier (used here) through terminal and it works perfectly.
Thank you.
I had the same problem, and I solved it by upgrading QtCreator. I think, 3.x.x versions of QtCreator incorrectly assumes the name of g++ compiler. In Kits options there is only "Compiler" setting, and in 4.x.x there are two separate string "C" and "C++". After indicating correct paths to both compiles "Cannot run compiler" error disappears.
So I'm using the new Bash on Ubuntu on Windows shell, and installed the clisp package to mess with Common Lisp. I get this error when I try clisp test.clisp:
/usr/lib/clisp-2.49/base/lisp.run: error while loading shared libraries: libavcall.so.0: cannot enable executable stack as shared object requires: Invalid argument
This is an entirely fresh install too. I looked in /usr/lib and found the libavcall.so.0 file, but I'm not sure what to do with it. How do I fix this issue?
This issue no longer exists with libffcall 2.0 or newer. It was fixed through this commit.
If you are still using libffcall 1.x: The FAQ (cited by user #cybevnm) explains most of it:
libavcall.so is flagged as requiring executable stack (property GNU_STACK has the value RWE), although it does not need an executable stack. This occurs because it was compiled from assembly-language source code.
You can remove this flag through a command such as sudo execstack -c /usr/lib/libavcall.so.0.
Typescript compilation task works fine on linux machines but on a mac fails with the following not particularly useful error message and what looks like a binary dump.
$ grunt
Running "ts:build" (ts) task
Compiling...
Fast compile will not work when --out is specified. Ignoring fast compilation
Using tsc v1.4.1
������������=��AF���=����
>> Error: tsc return code: 3
Warning: Task "ts:build" failed. Use --force to continue.
Aborted due to warnings.
Im using nvm with node v0.11.4 and rvm with ruby v2.2.0.
Any ideas how to fix this, or even debug?
As the question includes debugging, here are some pointers which might help determine where the problem is.
Try compiling from the command line with tsc alone (no grunt), in case the problem is with grunt or the ts:build task (looks like grunt-ts).
Maybe one of your source files is causing the tools to crash (perhaps they can't cope with a file's encoding?). If a single, simple file will compile, then try removing subsets of your source from the build. If some of those files are causing the crash (whether valid TypeScript or not) you may be able to find a temporary workaround.
Try compiling with different versions of tsc. If you need 1.4.1 features you could try using the latest from https://github.com/Microsoft/TypeScript (see here for how to do this with grunt-ts).
The problem was with a malfunctioning node installation. I upgraded to node 0.12 which fixed the problem.
Just to check the problem wasn't node 0.11.4 specific I removed all previous versions of node and reinstalled 0.11.4 and the error no longer occurs.
I took these steps after removing all node modules, clearing the cache and reinstalling with no luck. I also tried using multiple typescript compiler versions.
I've been working on a program called RoboJournal and I recently finished the 0.4.1 release. I'm currently in the process of packaging it for Fedora but for some reason the program won't compile on that OS. The exact same code builds fine on Windows and any Debian-based Linux (Debian itself, Ubuntu, Mint, et al). I had no problems packaging this for Debian. Here's the the compiler output error message (running on Fedora 18 KDE version):
/usr/bin/ld: dblogin.o: undefined reference to symbol 'XkbGetIndicatorState'
/usr/bin/ld: note: 'XkbGetIndicatorState' is defined in DSO /lib64/libX11.so.6 so try adding it to the linker command line
/lib64/libX11.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
The problem seems to be that the Linker can't find whatever is supposed to control the XkbGetIndicatorState signal (one of the X11 libs). This is used to determine whether caps lock is enabled while a certain dialog is active. Apparently, anything Debian-based includes this library out of the box while Fedora does not. I think this error is simply caused by a missing package but I'm not sure which one. Google gave me nothing useful. Any ideas?
Anyone who wants to test this for themselves can clone from git://github.com/pwizard2/robojournal.git. The app depends on the following packages (so far): qt, qt-assistant, qt-mysql, qt-devel, qt-webkit, qt-webkit-devel.
The problem is probably that you're not linking your program against libX11 so you need to add -lX11 to your link command and then everything will work.
The reason it works on some other linux distributions is that they allow symbols to be resolved using libraries that have only been pulled in indirectly - so if your program links against a library that is linked against libX11 then you will be able to call routines in libX11.
Fedora has not allowed this indirect linking (by default) for several years now (see UnderstandingDSOLinkChange) and several other distributions have also now followed suit.
I am using SQLite 3 for Database management in my ARM9 based microprocessor.
I want to cross compile the latest version of the SQLite 3 for my project in Linux (Ubuntu 10.04). I am using the arm-none-linux-gnueabi-gcc compiler for development.
I tried to cross compile using following commands,
Downloaded the sqlite-amalgamation-3.7.0.tar
I extract it and then write the following command on Terminal,
sudo ./configure --exec-prefix=/media/8CCC8E9BCC8E7F68/SQLIte3/sqliteinstall/ --host=arm --target=arm CC=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-gcc AR=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-ar STRIP=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-strip RANLIB=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-ranlib CFLAGS="-Os"
It successfully cross compiled the SQLite.
Then,
sudo make command.
It successfully run.
Now "make install " command.
It did not give me an error but when i went to the config.log file i found there is some sentences as following,
1.conftest.c:17:7: error: size of array 'off_t_is_large' is negative
2.conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
compilation terminated.
3.conftest.cpp:23:28: error: ac_nonexistent.h: No such file or directory
4.conftest.c:67:13: error: invalid type argument of unary '*' (have 'int')
I doubt that weather it has been cross compiled properly or not.
I can not understand.
I inserted the library on my board it works fine but the problem is that the speed got very slow. I think there is some problem that i have not set any flags for the GCC compiler.
I could not find any options.How I can set the particular flags for the GCC compiler so that unnecessary features can be omitted.
You probably shouldn't try to do cross-compilation manually. Instead, use an embedded Linux build system that will do that for you, and automate the cross-compilation process entirely. My favourite is of course Buildroot (http://buildroot.org), but there are plenty of others (with varying levels of quality, complexity and features) : OpenEmbedded, Yocto, PTXdist, etc.