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.
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.
I recently upgraded to Architect version 0.9.7 on my Win 7 machine. However, after starting Architect, the RJ console wouldn't launch and I got the error message:
‘Launching the R Console was cancelled, because It seems starting the R engine failed.”
Please make sure that R package 'rj' (2.0 or compatible) is installed and
that the R library paths are set correctly for the R environment
configuration 'Embedded R Server'.
I installed the packages ‘rj’ and ‘rj.gd’ through the RTerm run console (which does happen to work) within Architect using the command suggested on www.walware.de:
install.packages(c("rj", "rj.gd"), repos="http://download.walware.de/rj-2.0")
Then, I restarted windows, and restarted Architect. Same error message. I zoomed in on the details of the error message and noticed the following line:
SEVERE: Path to rj package not found. Use R_LIBS or java property
'de.walware.rj.rpkg.path' to specify the location.
So I opened an RTerm run console to check whether any of my .libPaths() locations contains the directories ‘rj’ or ‘rj.gd’. Oddly enough, they do. My first .libPaths path contains both packages. So that doesn’t seem to be the reason.
How could this be fixed?
I received prompt and helpful feedback from Open Analytics (thanks!), who informed me that the problem is due to changes in Java 8. With Java 7, Architect works fine. The next release of Architect will incorporate the changes in Java 8.
In order to get it work with Java 7, enforce the use of a specific Java Runtime, by using the -vm argument in the architect.ini file as follows:
-vm
C:\Program Files\Java\jre7\bin\javaw.exe
(mind the line break, which is required)
This is particularly useful if you have several Java versions on your system where the default Java is not suitable for use with Architect. The architect.ini file is found directly at the top level of the installation folder of Architect. You can find out where this is by looking at the Properties of the Architect shortcut on your desktop.
N.B. the -vm argument should be put before the -vmargs argument otherwise it is simply ignored!
N.B. examples of -vm specification on GNU/Linux and Mac OS X:
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Linux_Example
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Mac_OS_X_Example
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.
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.