I'm cross compiling Qt program to U-touch using arm-poky-linux-gnueabi-gcc.
When I execute the following command, I get the error message below:
arm-poky-linux-gnueabi-gcc -o try main.cpp -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -lQtCore -lQtGui
Error Message:
/opt/poky/1.2.1/sysroots/i686-pokysdk-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.6.4/ld: cannot find -lQtCore
/opt/poky/1.2.1/sysroots/i686-pokysdk-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.6.4/ld: cannot find -lQtGui
What am I doing wrong?
The compiler (or better, the linker) cannot find a copy of the libraries to link to.
Solution:
Put a copy of the Qt libraries for the target on the host.
Then, provide their path to gcc with the -L /path/ option.
Related
I need help with installing a software.
In general: I try to install PostGIS on a cluster (CentOS) and do not have admin rights. There is a sqlite3 installation (connected to the error), but this seems corrupt. My own one usually works and has (also by install-process) been used previously.
I cannot use yum.
In detail:
For having the MakeFiles build I set flags as I believe to possibly need them:
./configure --prefix="$HOME/.local" CFLAGS="-I$HOME/.local/include" LDFLAGS="-L$HOME/.local/lib" LT_SYS_LIBRARY_PATH="$HOME/.local/lib" LIBS="-L$HOME/.local/lib" SQLITE3_CFLAGS="-I$HOME/.local/include" SQLITE3_LIBS="-L$HOME/.local/lib"
But the following error is thrown when running make:
/usr/bin/sed: can't read /usr/local/lib/libsqlite3.la: No such file or directory
libtool: error: '/usr/local/lib/libsqlite3.la' is not a valid libtool archive
Right after (but I don't see the connection):
libtool: link: ranlib .libs/liblwgeom.a
If I run make again, it jumps that directory. But gets stuck with a similar error (which is not jumped by running make another time):
/bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -std=gnu99 -I<exp. $HOME>/.local/include -fno-math-errno -fno-signed-zeros -fPIC -DPIC -I../rt_core -I../../liblwgeom -I<exp. $HOME>/.local/include -I/usr/include/gdal -I<exp. $HOME>/.local/include ../rt_core/librtcore.a raster2pgsql.o -L<exp. $HOME>/.local/lib -static ../../liblwgeom/liblwgeom.la -L/usr/lib64 -lgdal -L<exp. $HOME>/.local/lib -lgeos_c -lc -lm -o raster2pgsql
libtool: error: cannot find the library '/usr/local/lib/libsqlite3.la' or unhandled argument '/usr/local/lib/libsqlite3.la'
I don't get why libtool searches in '/usr/local/lib/'. I didn't find that hardcoded in libtool or the MakeFiles. I'm clueless - and this is above my skill (apperently).
Can you help me?
One of the dependencies (proj) linked in its .la file to the malicious sqlite3 version. Reinstalling this dependency solved the issue.
What would help in similar cases would be to search the 'wrong path' in the dependencies:
find <deps lib dir> -type f -exec grep -l "<wrong path>" {} +
Kudos go to https://stackoverflow.com/a/62500481/14339502 who stated the valuable hint that "it seems like you have some other .la file that references it".
I am using qmake to cross-compile my ARM based program on Ubuntu. I have ran into the multithreading issue as described in this thread:
C++ 11 Threads, Error Pure virtual function called
One answer suggests adding the flag to the compilation as:
g++ -pthread -std=c++11 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} thread1.cpp
I am not sure how to add this -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} in my qmake project file.
I did QMAKE_CXXFLAGS += -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4}. My error still remains so I wanted to confirm if this is the right way to add that flag.
It's a bash glob/wildcard. Expands to
-D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
I want to install libQGLViewer, which I downloaded from http://www.libqglviewer.com/download.html on Ubuntu 10.04. According to the manual I have to do;
1) cd QGLViewer/
2) qmake
3) make
Compiling the library by typing make almost immediately ends in error however;
`c++ -c -pipe -Wall -W -Os -fPIC -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/macx-g++ -I. -I/usr/include/qt3 -I/System/Library/Frameworks/OpenGL.framework/Headers -I/System/Library/Frameworks/AGL.framework/Headers/ -I.moc/ -o .obj/qglviewer.o qglviewer.cpp
In file included from domUtils.h:23,
from qglviewer.cpp:23:
config.h:77:22: error: QGLWidget: No such file or directory
config.h:88:17: error: QList: No such file or directory
config.h:89:19: error: QVector: No such file or directory
In file included from qglviewer.cpp:23:
domUtils.h:25:23: error: QDomElement: No such file or directory
domUtils.h:26:19: error: QString: No such file or directory
domUtils.h:27:23: error: QStringList: No such file or directory
domUtils.h:28:18: error: QColor: No such file or directory
`
this goes on for a while and ends in:
`qglviewer.cpp:841: error: ‘height’ was not declared in this scope
qglviewer.cpp: At global scope:
qglviewer.cpp:864: error: variable or field ‘timerEvent’ declared void
qglviewer.cpp:864: error: ‘QTimerEvent’ was not declared in this scope
qglviewer.cpp:864: error: expected primary-expression before ‘)’ token
make: *** [.obj/qglviewer.o] Error 1
rcar#DUD3642RCAR:~/Downloads/libQGLViewer-2.5.1/QGLViewer$
`
I think this is because it cannot find the QT library. But I have installed QT 5.2 using the latest download from http://qt-project.org/downloads.
Could it be the Makefile just can not locate the library path? And if so I how do I mend this?
Solved it! I missed qtcreator for this; sudo apt-get install qtcreator
I also needed an upgrade to Ubuntu 12.04 because on 10.04 this problem persisted.
I'm trying to use this sqlite extension to calculate stdev in Sqlite dbs, on Linux, I use this command to compile the lib
gcc -fPIC -lm -shared extension-functions.c -o libsqlitefunctions.so
but seems that the .load command is not in the sqlite .help command list, and I got error:
unknown command or invalid arguments: "load". Enter ".help" for help
Same thing happens when I use the command:
sqlite> SELECT load_extension('./libsqlitefunctions.so');
SQL error: no such function: load_extension
I tried to use this instruction to compile sqlite:
0. untar latest sqlite3 source code in a new directory
1. cd to the newly untarred sqlite directory
2. Comment out the line in Makefile.in to enable loadable extensions:
# TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1
3. ./configure LIBS=-ldl && make sqlite3
4. export LD_LIBRARY_PATH="`pwd`:$LD_LIBRARY_PATH"
5. gcc -I`pwd` -shared src/test_loadext.c -o half.so
6. ./sqlite3
But couldn't find the line "TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1" in the newest Sqlite source code.
It looks like configure was updated but not the documentation. Try
./configure --enable-dynamic-extensions
The reference is the configure source code. Digging further, it looks like the dynamic extensions are enabled by default. From README:
The generic installation instructions for autoconf/automake are found
in the INSTALL file.
The following SQLite specific boolean options are supported:
--enable-readline use readline in shell tool [default=yes]
--enable-threadsafe build a thread-safe library [default=yes]
--enable-dynamic-extensions support loadable extensions [default=yes]
So I think load is present. It's the second part of the error invalid arguments that's the problem.
The cause seems to be that you're using Linux instructions. That won't work. Macs don't generally have .so files, which is what your compilation command is generating.
The method of compiling and loading a Mac dynamic library, loadable as an extension, is at this location. The compile command is going to look something like
gcc -bundle -fPIC -I/path-to-sqlite/sqlite3 -o filename.sqlext filename.c
Note the -bundle and -fPIC that are important for dynamic loading, but which you were missing. The resulting filename will be filename.sqlext, so use that in your path.
It may be worth noting that you may get a "missing symbols" error when you load the library - this is due to the fact that the -lm flag needs to be at the end of the compile command thus:
gcc -fPIC -shared extension-functions.c -o libsqlitefunctions.so -lm
Regards Fat jonnie
Using glew, I'm trying to link the simple program
#include </usr/include/GL/glew.h>
int main (int argc, const char * argv[])
{
glewInit();
return 0;
}
in XCode 4, under OSX Lion, which reports the error:
ld: library not found for -lGLEW.1.7.0
Command /Developer/usr/bin/clang++ failed with exit code 1
however, the error output also reports the following flags for the linker
-mmacosx-version-min=10.7 -L/usr/lib -lGLEW.1.7.0 -lglfw -framework OpenGL -framework Cocoa
and indeed, libGLEW.1.7.0 does reside in /usr/lib
Moreover, if I try to build the program by hand, with
gcc -L/usr/lib -lGLEW.1.7.0 main.cpp
I get an a.out file without any errors reported (which if run causes a segmentation fault, but maybe that's to be expected)
Any ideas on what might be causing XCode to produce this error and how it could be avoided?
Built and installed GLEW myself and had the same issue with plain gcc inside a makefile on OS X with compilation of code from https://github.com/jckarter/hello-gl
The following steps resolved the issue:
I found my GLEW libs (libGLEW.a and libGLEW.dylib) installed in /usr/lib directory (it definitely was there owned by root with r permissions for others). Tried to change GLEW_LIB variable from the makefile to /usr/lib but still got ld: library not found for -lGLEW
after that I tried to link compiled program against static library directly (without -l flag) - for that I removed -lGLEW from gcc command and changed it to direct link t library /usr/lib/libGLEW.a - it compiled and linked fine
Ok - it's a work around to try first
Then I created two links to my libraries with the following commands:
ln -s /usr/lib/libGLEW.a /usr/local/lib/libGLEW.a
ln -s /usr/lib/libGLEW.dylib /usr/local/lib/libGLEW.dylib
and finally got it working with original makefile (only changed GLEW_LIB variable to /usr/local/lib).
Probably GLEW's make install should place libraries to /usr/local/lib directly.
(I have removed this from an edit to the question and posted it as an answer, as per leppie's suggestion)
I might have found the answer in some details I had considered unimportant in my original post. So here goes, in case others might encounter a similar problem.
Apparently, XCode4 projects use clang++ by default, which in the link phase accepts a parameter -isysroot (which apparently ld does not accept).
Now, if in your build settings (as was my case) your Base SDK has been defined as something other than Current Mac OS, the parameter -isysroot will be introduced with the value of a directory pointing to that SDK, thus (this is my guess) prepending this to all other lib directories you might be including with -L.
In my case, -L/usr/lib was effectively turning into -L/Developer/SDKs/MacOSX10.7.sdk/usr/lib which does exist and did not contain libGLEW, hence the error "library not found"