I am trying to deploy a Qt application by providing the Qt libraries as shared libraries in a directory and pointing ld to them using LD_LIBRARY_PATH. This works for all Qt libraries such as libQt5Network or libQt5Gui, but not for libQt5Core which is somehow not found and the system version is used instead.
Using LD_DEBUG=all I can see that ld tries the file which exists, but skips it
3705: file=libQt5Core.so.5 [0]; needed by ./app.bin [0]
3705: find library=libQt5Core.so.5 [0]; searching
3705: search path=/home/user/app/lib:/usr/lib64/tls/x86_64/x86_64:/usr/lib64/tls/x86_64:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/x86_64/x86_64:/usr/lib64/x86_64:/usr/lib64/x86_64:/usr/lib64 (LD_LIBRARY_PATH)
3705: trying file=/home/user/app/lib/libQt5Core.so.5 <- this file exists
3705: trying file=/usr/lib64/tls/x86_64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/tls/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/tls/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/tls/libQt5Core.so.5
3705: trying file=/usr/lib64/x86_64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/x86_64/libQt5Core.so.5
3705: trying file=/usr/lib64/libQt5Core.so.5
Both libQt5Core.so.5 and app.bin are 64 bit elf.
Is there any way to find out why ld rejects the file?
Solution is here: https://github.com/Microsoft/WSL/issues/3023
The library contains an ABI note which can be removed using strip to make ld accept the library.
The other answer is correct. Just in case the link there gets broken, here's what happened in my case and how I fixed it.
I was running an older kernel, version 3.10, on a system where Qt5 was installed. One of the libraries – namely, libQt5Core.so.5.11.0, has an ELF section .note.ABI-tag, which specifies that the library was compiled for kernel 3.17.0. Presence of this section can be seen via e.g.
objdump -sj .note.ABI-tag /path/to/library.so
And the fact that it's compiled for a newer kernel is revealed by file, with the hard to notice note, "for GNU/Linux 3.17.0", near the end of its output. In my case it was:
/opt/qt511/lib/libQt5Core.so.5.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.17.0, BuildID[sha1]=df5f7e933899d1ff629145ab7ca35b2f9bc41843, stripped
So the fix in my case was to run
strip --remove-section=.note.ABI-tag /path/to/library.so
which removed this section and allowed the library to load.
Beware though, that if you do this, you explicitly break the assumptions the library build system may have used, so things may break. In my case they didn't, though.
Related
On its website OpenFlipper says it can be compiled in three steps as:
cd build
cmake ..
make # or, even better, make -j8
However I get an error saying Qt is unable to be found at the cmake step and that I should specify a QT5_INSTALL_PATH. However even if I do this OpenFlipper is still issuing the same complaint!
You are not supposed to specify where Qt is installed in the QT5_INSTALLED_DIR but prior to that as environment variable in your terminal:
# assuming Qt was installed in your home directory, as is default
export CMAKE_PREFIX_PATH=~/Qt5.7.0/5.7/gcc_64/
# note that you now have to call cmake etc from that process
Compiling and running it after that you might get errors telling you GL_ARB_vertex_buffer_object is not present, even if your glxinfo | grep ARB_vertex_buffer is telling you it is.* Clicking "Ignore" results in a crash. To mitigate this, you have to manually change (4,3) to (3,0) in
OpenFlipper/widgets/coreWidget/CoreWidget.cc
If you still experience errors, try deleting your cmake cache, this is accomplished by using cmake-gui (was in the package cmake-qt-gui for me) and hitting "Delete Cache"
(optional) remove the very annoying warning message you get at every start of OpenFlipper by removing the line concerning "renderers shipped" in
OpenFlipper/Core/Core.cc
*: My teaching assistant told me that there is a bug in Qt (<5.9) that forces OpenFlipper to use the OpenGL Compatibility Profile. Additionally Intel and AMD drivers hand back an OpenGL 3.0 Core Context when asked for an OpenGL 4.3 Compatibility Context (my TA described this behavior as a "bug", I'm not so sure about this), leading to a crash in Qt. So this should be resolved in Qt 5.9 (not out yet). This seems to affect also mainly integrated graphics, so one could try using a dedicated GPU.
Trying to get GtkAda to work. Didn't compile the lib myself, had a lot of problems and finally I found a precompiled library on the internet. Of course GPS didn't find it even after adding it to my path...
So I added it manually to my project and GPS began the compilation. It is just a simple example to see if everything works. Just beginning to learn programming.
WITH Gtk.Main ;
USE Gtk.Main ;
WITH Gtk.Window ;
USE Gtk.Window ;
WITH Gtk.Enums ;
USE Gtk.Enums ;
PROCEDURE MaFenetre IS
win : Gtk_window ;
BEGIN
Init ;
Gtk_New(win,Window_Popup) ;
win.show ;
Main ;
END MaFenetre ;
Which gave me this error:
gnatlink /Users/laurentlutgen/GPS/mafenetre.ali -o
/Users/laurentlutgen/GPS/mafenetre
Undefined symbols for architecture x86_64:
"_ada_c_enum_value_size", referenced from:
.
.
.
"_pango_tab_array_new", referenced from:
pango_tabs__pango_new in pango-tabs.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit
status gnatlink: error when calling /usr/local/gnat/bin/gcc
gnatmake: * link failed.
[2013-08-01 21:16:46] process exited with
status 4 (elapsed time: 09.38s)
The list of files the compiler complains about is quite long so.
Anyone an idea how to solve this.
I use the last version of gnat (2013) from AdaCore for MacOS X. I use MacOS 10.8.
The GtkAda library is xadalib 2012.
Thanks
Laurent
From what I see, gnatlink does not get passed the libraries needed to link against. You said that you added GtkAda to your project manually. By doing this, you probably missed all the linker options specified in the *.gpr file of GtkAda, so your binary does not get linked against the GTK+ library.
I suggest you try to get GPS to find the installed GtkAda project file. You can do this by setting ADA_PROJECT_PATH before launching GPS. If GtkAda is located in GNAT GPL's default path, it looks like this:
$ export ADA_PROJECT_PATH="/usr/local/gnat/lib/gnat"
$ gps
You said you're using a precompiled binary you found on the internet. Are you aware that GtkAda is bundled with the GNAT GPL compiler? You should use that, unless you want to use gtk-quartz as backend (which doesn't require X11). If that's the case, you may find the instructions I wrote for compiling GPS with gtk-quartz helpful (as Simon already noted).
If you want, you can try my GPS port to OSX. By default, it is able to load the *.gpr files bundled with GNAT GPL. On the Usage page, you find instructions of how to change the ADA_PROJECT_PATH if you installed your GNAT somewhere else.
For further help, you should post the *.gpr file of your project.
Edit:
I stand corrected: GtkAda is in fact not included in the GNAT GPL distribution for whatever reason. As XmlAda is included as project to link against, I was sure GtkAda was too, but it isn't; so using XAdaLib seems to be the easiest option. You have to point ADA_PROJECT_PATH to the installation directory of XAdaLib instead of the usual GNAT one to be able to use GtkAda.
As far as I know none of the GPL'ed GNATs from AdaCore for x86 have the capability to generate 64-bit code. I think I read something to that effect somewhere but cannot remember where.
The issue also came up in the Ada-port of Doom3, so if you can find him he might know for sure.
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.
I have an library (flam3) that depends on a few utility libraries from unix (xml2, jpeg, png, z) and I am trying to make an application on Lion that uses it. I am building with the latest Xcode and when I try to link with the libraries from fink, macports, and homebrew I get the same error:
ld: warning: ignoring file /opt/local/lib/libxml2.a, file was built
for archive which is not the architecture being linked (i386)
and the libraries look different from ones that work:
bash-3.2$ file /sw/lib/libxml2.a
/sw/lib/libxml2.a: current ar archive random library
by comparision
bash-3.2$ file ~/Documents/FLAM3/libflam3.a
/Users/spot/Documents/FLAM3/libflam3.a: Mach-O universal binary with 2
architectures
/Users/spot/Documents/FLAM3/libflam3.a (for architecture x86_64):
current ar archive random library
/Users/spot/Documents/FLAM3/libflam3.a (for architecture i386):
current ar archive random library
that's the library that I compiled with Xcode.
Is there any way to get Xcode to accept this library? Is there any way to get fink/macports/homebrew to generate a library that works with Xcode? Seems like I am "doing it wrong" as these projects would all be useless if everyone had this problem.... but I don't feel like I've done anything unusual. Help?
The problem is that your libxml2.a is not built as "Universal binary". I.e. it doesn't contain all necessary architectures (In your case I believe it is i386). You need to ask fink, macports, or homebrew to build/download/install library with all necessary platforms. I know that macports has such flag (I don't remember how it's called).
The "file" command list all available architectures for .a file only when the file is trully universal (contains two or more of ppc, i386, x86_64), otherwise it only shows the vanilla "ar archive..." message. That confirms your libxml2.a has only one architecture.
The problem is not in Xcode or Lion. Possibly the default link architecture on Lion changed.