I have this strange situation that after updating Qt from 4.8 to 5.3, Qt Creator (v.3.2.1) will not take any keyboard input. The keyboard is working normally in other applications.
I'm on Debian Wheezy (7.7) with XFCE, but installed the Qt5 set of packages from wheezy-backports.
Does anyone have an idea what can be done about this?
Update:
As requested, here's the Terminal output:
libEGL warning: DRI2: failed to authenticate
xkbcommon:ERROR: failed to add default include path auto
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an addtional search path,
add ':' as separator to provide several search paths and/or make sure that XKB
configurationdata directory contains recent enough contents, to update please see
http://cgit.freedesktop.org/xkeyboard-config/ .
It is apparently a known bug, some messages and posts talks about this issue on the Internet.
Maybe try this, from https://lists.debian.org/debian-backports/2014/10/msg00061.html
Opening Qt5 applications from backports (or self compiled against backported
Qt5) have some trouble finding XCB data:
$ /usr/lib/x86_64-linux-gnu/qt5/examples/quick/d
ialogs/systemdialogs/systemdialogs
xkbcommon: ERROR: failed to add default include path auto
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an additional search
path, add ':' as separator to provide several search paths and/or make sure
that XKB configuration data directory contains recent enough contents, to
update please see http://cgit.freedesktop.org/xkeyboard-config/ .
Applications run fine, but can't get input from the keyboard.
As the warning points out, setting the environment variable fixes it:
export QT_XKB_CONFIG_ROOT=/usr/share/X11/xkb
So, try to run qtcreator with the folowing command:
export QT_XKB_CONFIG_ROOT=/usr/share/X11/xkb && qtcreator
~]$ /usr/local/bin/xca
xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
Qt: Failed to create XKB context!
Use QT_XKB_CONFIG_ROOT environmental variable to provide an additional search path, add ':' as separator to provide several search paths and/or make sure that XKB configuration data directory contains recent enough contents, to update please see http://cgit.freedesktop.org/xkeyboard-config/ .
sudo apt-get install xkb-data (xkeyboard-config)
has solved my problem (no input from keyboard)
Related
I've been trying to install LuaJIT on Windows 10 for some time following the official guide, and I actually get to install it. For example, if I execute luajit I get into the prompt. Also, luajit -v returns the version of luajit (2.0.4). And I can also execute code with luajit -e <lua code>. However, whenever I try to save bytecode with luajit -b, I get the following message:
luajit: unknown luaJIT command or jit.* modules not installed
I tried to make all sort of installations: using Cygwin, luajit-rocks, MinGW, ... However, no matter what I try, I always get the same result, and I have no clue of what to do.
Could you point me to some potential problems I might be overlooking?
I have on my system Lua 5.1 and Luarocks.
Some extra LuaJIT features are implemented as separate Lua modules (e.g. jit.bcsave for bytecode saving), and LuaJIT depends on package.path to find those modules. The suggested install location for those modules is in the default package.path, but if you override it via the LUA_PATH environment variable, you have to make sure to include that location there. One easy way to do that is to put two consecutive semicolons into LUA_PATH: Double semicolons are replaced by the compile-time default value of package.path.
You need place modules to "jit" folder near with juajit.exe. That folder include some system modules (bcsave too). package.path can dont work, becouse it hardlinked, how i understand. That folders distributed with source code.
Download lua from official sice: https://luajit.org/download.html
You can see "jit" folder inside archive:
LuaJIT-2.0.5.zip\LuaJIT-2.0.5\src\jit\
I am trying to experiment with AUBIT4GL, an Informix clone. I am running into a problem with the process as the steps outlined in the manual and the instructions given in the ./etc/aubitrc file seem to be a tad incomplete.
My questions are:
What is the purpose of the ./configure and ./make scripts in the distribution directory given that the software is distributed as a binary package and the install instructions make not reference to them?
Where is the env TARGET_OS set and why is there no reference to this setting in the install instructions when failing to define it causes the aubit program to fail?
Is anyone else besides me using this software or has attempted to?
If you're running on Linux - always trying compiling from source.
If you must run from binary - you dont need to do anything with the ./configure or make.
Just point $AUBITDIR to the code.
set PATH to include $AUBITDIR/bin
set LD_LIBRARY_PATH to include $AUBITDIR/lib
and you should be good to go.
For Windows - its pretty much the same - except compiling from source is a massive pain - so use the binary ;)
There - you need to have PATH include both %AUBITDIR%/bin and %AUBITDIR%/lib
In both cases - you'll likely need to make some configuration settings (what type of database, what UI etc etc)
If you're using Informix on Linux, setting :
export A4GL_UI=TUI
export A4GL_SQLTYPE=esql
will probably be enough (if they are not defaulted in the $AUBITDIR/etc/aubitrc)
I'm trying to deploy ImageMagick with my own software. On windows I've just included all the core dlls with coders dlls at the exe path and it works well.
But on mac os I have troubles with coders. I installed ImageMagick via macports and found it with the help of CMake. CMake does all the job of copying and fixing up all the core libs I've linked against. Then I copied all the coder libs and fixed them up also, but when I start my application it just can't find any coder. So I'd like to know what am I missing there.
Note: if I didn't fix up any paths it works well. It is only my deployment that is in trouble. Maybe I should include some kind of config file?
P.S. I have all ImageMagick libs including coders SOs near the executable in MacOS bundle sub-folder.
How about setting the MAGICK_CODER_MODULE_PATH in your bundle?
see here: http://www.imagemagick.org/script/resources.php
EDIT:
To improve the information:
Originally when embedding IM in our own app bundle we had three problems:
our app and the IM dylibs not finding referenced IM dylibs,
IM not finding its config files,
IM not finding coders (the No Decode Delegate error)
We tried changing the hardcoded paths in the dylibs using the install_name_tool but finally when doing some tests with moving the IM around to different directories and testing
convert -debug configuration
we found out the all three above problems could be solved just by setting and exporting at least these three environment variables in the terminal console before running convert:
DYLD_LIBRARY_PATH
MAGICK_CONFIGURE_PATH
MAGICK_CODER_MODULE_PATH
With this experience, we returned back to our bundle and in the beginning tried to use the Info.plist fiel to set these variables but it didn't seem to work - probably because there were problems with making the paths to IM inside the bundle relative.
Finally we created a simple sh script and put it into our bundle and configured this bundle to run this script instead of the main app:
#!/bin/sh
CURR_DIR="$( cd -P "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
IMAGE_MAGICK_PATH=$CURR_DIR/../Resources/ImageMagick
export DYLD_LIBRARY_PATH=$IMAGE_MAGICK_PATH/lib
export MAGICK_CONFIGURE_PATH=$IMAGE_MAGICK_PATH/lib/ImageMagick-6.8.0/config
export MAGICK_CODER_MODULE_PATH=$IMAGE_MAGICK_PATH/lib/ImageMagick-6.8.0/modules-Q16/coders
# run application
exec $CURR_DIR/OurAppName
The key thing to make it working was properly getting the CURR_DIR of the app bundle (thanks to this post).
And as came out of our tests, setting the environment variables this way makes them visible only for this application execution context - i.e. when we started our app using the bundle, opened terminal and typed
env
the above three variables were missing from the output.
Hope this will help others save couple of days of research and pulling hairs out of their heads ;)
I've found a full solution for deploying ImageMagick in a bundle with the help of CMake. If you don't use CMake then #Tomasz's answer will be of help also.
So let's start:
First of all you need to know what and where ImageMagick is trying to locate when it is used from your own code. To find it out you can use MAGICK_DEBUG environmental variable which could be set to those parameters. It really helps when you debug ImageMagick.
Prerequisites:
I assume that you used FIND_PACKAGE and FIXUP_BUNDLE to find ImageMagick and set its binary paths inside the bundle. The only thing left is to deploy coders. Also I assume that you've installed ImageMagick from Mac Ports.
We need to get ImageMagick version string to correctly locate the coders:
STRING(REGEX REPLACE "-.+" "" ImageMagick_SHORT_VERSION ${ImageMagick_VERSION_STRING})
Now ImageMagick_SHORT_VERSION contains full version without any sub versions.
Then we need to copy all the coders to some predefined folder(I've used ImageMagick/coders subfolder under MacOS part of the bundle)
FILE(COPY /opt/local/lib/ImageMagick-${ImageMagick_SHORT_VERSION}/modules-Q16/coders/ DESTINATION ${PATH_TO_YOUR_BUNDLE}/Contents/MacOS/ImageMagick/coders/)
Now we need to fixup all the *.so libs we have, so we list it and pass to fixup_bundle
FILE(GLOB IMAGEMAGICK_CODERS ${PATH_TO_YOUR_BUNDLE}/Contents/MacOS/ImageMagick/coders/*.so)
Now we should update *.la files which accompanies coders *.so. To achieve it I've used script:
INSTALL(SCRIPT LaScript.cmake COMPONENT Runtime)
Script content:
SET(TARGET_BINARY_DIR "${PATH_TO_YOUR_BUNDLE}")
FILE(GLOB IMAGEMAGICK_CODERS_LA ${TARGET_BINARY_DIR}/Contents/MacOS/ImageMagick/coders/*.la)
FOREACH(file ${IMAGEMAGICK_CODERS_LA})
FILE(READ ${file} FILE_CONTENT)
STRING(REGEX REPLACE "dependency_libs='.*'" " " MODIFIED_FILE_CONTENT ${FILE_CONTENT})
STRING(REGEX REPLACE "libdir='.*'" " " MODIFIED_FILE_CONTENT ${MODIFIED_FILE_CONTENT})
FILE(WRITE ${file} ${MODIFIED_FILE_CONTENT})
ENDFOREACH()
We almost ready the only thing left to be done is to change the way we launch the application. But let's digress a little bit and find out where ImageMagick searches for the coders:
It tries to get the content of MAGICK_CODER_MODULE_PATH environmental variable
Then it checks if MAGICKCORE_CODER_PATH macro is defined(and in fact it does!) and use its value.
Then it will try to use MAGICK_HOME environmental variable and MAGICKCORE_CODER_RELATIVE_PATH to get path to the modules but we don't care since we will stop on #2 anyway!(NOTE: that it is true for Mac Ports installation)
So the only way we can interfere with search is to set MAGICK_CODER_MODULE_PATH environmental variable(Well we can also edit libMagickCodre and replace MAGICKCORE_CODER_PATH with some static path we need but it is too britle way to do things and it won't save us if someone set MAGICK_CODER_MODULE_PATH anyway)
We shouldn't set it system wide since we can break some user installtion so we have 2 options:
Use LSEnvironment to set the MAGICK_CODER_MODULE_PATH to some predefined location
Use script to launch our app and set this variable inside it.
I've chose the later since it is more flexible,
I have the following script:
#!/bin/bash
working_dir="${0%/*}"
export MAGICK_CODER_MODULE_PATH=$working_dir/ImageMagick/coders
executable="${working_dir}/ApplicationName"
"$executable"
and set CFBundleExecutable to the name of the script.
That's all and I hope it will help someone to save his/her time.
You should follow the Mac OS X-specific Build instructions but specifying --enable-shared in the configure options (see this document for details).
I guess that your application can't find the codecs because they have been statically linked to ImageMagick tools. This is usually done to address portability issues. To make codecs available in your application, you should build them as shared objects.
Fed up with emacs22 that came with Xcode, I set out to upgrade to emacs24. I do not want to overwrite the system defaults, and do not want to mess up with it either, so I tried to install emacs in a custom directory other than /usr/local/.
Say I set the prefix to CUSTOM_DIR/emacs-24.2. I built and installed emacs 24.2 to the CUSTOM_DIR/emacs-24.2 directory, so bin/, libexec/, share/, and var/ are all there. (Yes, I have manually checked all required files; the installation is totally complete in the custom directory.) But when I tried to run the new version of emacs, I got the following error messages:
Warning: arch-dependent data dir (/usr/local/libexec/emacs/24.2/x86_64-apple-darwin12.2.1/) does not exist.
Warning: arch-independent data dir (/usr/local/share/emacs/24.2/etc/) does not exist.
Warning: Lisp directory `/usr/local/share/emacs/24.2/site-lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/site-lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/24.2/lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/24.2/leim' does not exist.
Error: charsets directory not found:
/usr/local/share/emacs/24.2/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!
So obviously emacs's search path was not affected despite the option --prefix=CUSTOM_DIR/emacs-24.2 I specified when running configure. How do I fix this? Is there any configuration files I need to change, or do I need to add some configuration options when configuring and building emacs? (I built emacs 24.2 from tarball.)
P.S. Please do not suggest other ways of installation. I do know how to install emacs 24, either by installing to /usr/local/, which appeared to have no problem at all; or with MacPorts or similar projects; or by directly running from the command line component found in Emacs.app binary distribution. I simply want to fix this very problem. Thanks.
When using homebrew to install graphviz, the script gets to the point of "Making install in tkstubs" and then throws the following fatal error:
In file included from tkStubLib.c:15:
/usr/include/tk.h:78:11: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
I have installed XQuartz as X11 has been dropped in Mountain Lion, but I'm unsure if it is installed correctly. The location of Xlib.h is:
/opt/X11/include/X11/Xlib.h
There are also two symlinks to /opt/X11, they are:
/usr/X11
/usr/X11R6
Does this look like the correct setup to you? I've never dealt with X11 or XQuartz until yesterday.
Cheers.
After installing XQuartz you may add a symlink to your X11 installation folder by just entering
ln -s /opt/X11/include/X11 /usr/local/include/X11
in terminal. That will fix the problem as well without changing any ruby script.
You need to tell the tkstubs build (and possibly other bits in the package as well) to look for headers in /opt/X11/include; this is not on the standard include path.
Usually this is achieved by passing -I/opt/X11/include as an additional compiler flag, the method to do so is however dependent on the build system.
For reasonably modern configure scripts, the best approach is to pass it in the environment variable CPPFLAGS; if the package uses another build system or this doesn't work for another reason, then you need to look at the Makefile in the build directory.
You can enter in your shell before the compile/link (or brew) command:
export CPPFLAGS=-I/opt/X11/include
The export line will tell the compile/linker to look in /opt/X11/include for the X11 include files
Had the same issue and running this command on terminal
xcode-select --install
worked for me. Run this command after installing xQuartz.
If you need this to work in your CMake builds:
if(APPLE)
include_directories(AFTER "/opt/X11/include")
endif()
That worked well for me.
I got it to install by copying the x11 header file directory to the /opt/local/include directory. Probably not the best way to work around it but quick and easy.
I found this thread while trying to compile ffmpeg from source on OS X. I needed --enable-x11grab and the homebrew build does not support this option.
I had XQuartz installed already but I kept getting errors from ./configure: ERROR: Xlib not found. I thought the answers here would solve my problem, but they did not!
So, if anyone is ever in the same boat, my solution was this:
I opened up the generated config.log and found lots of errors referring to various includes and header files, including X11/Xlib.h - this is misleading. At the very bottom of the logfile was the key, pkg-config was complaining about looking for xbc.pc, and requested that it be put on the path. However, the error message that is displayed on the terminal says nothing about pkg-config or xbc!
The solution is to add to your PKG_CONFIG_PATH environment variable. Mine was nonexistent, so I just did export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig/ (the folder where I found xbc.pc).
I reran configure and everything worked like a charm!
TL;DR: check config.log - don't trust the terminal output!
Since the make file is looking for X11/xlib.h i.e., it is looking for X11 folder in the current directory, one way to solve this problem is to simply copy the /opt/X11/include/X11 directory to the directory that contains make file.