I am using libzbarQT (libzbarQT.so) in my QT code.I am facing an error while building the code saying "undefined reference to QWidget::qwsEvent(QWSEvent *event)".I am not using this function in my QT code.I want to know which function is internally calling this function so that I can tweak the library a bit.
Any suggestions please..
Thanks in advance for any help.
PS: I am crosscompiling my code using arm-none-linux-gnueabi-g++ toolchain with LTIB.
To solve error '/usr/lib/libzbarqt.so: undefined reference to QX11Info::display()', I have build Qt with X11.Now I am getting error:libzbarqt.so: undefined reference toQWidget::qwsEvent(QWSEvent*)' error.
In general, you could make sure that the symbols are present in the library unless it is built without symbols. I usually use the nm -a and objdump utilities for that operation.
More to the point: it seems that the zbar dynamic library that you have was built against the embedded version of Qt rather than the desktop Linux.
It is an unfortunate issue that both versions have the same dynamic library file names, so things like ldd cannot be much of help.
You will need to make sure to use exactly the same version of Qt installation that the library was built against. This means, if you use the desktop Linux installation for this, it will not work.
Related
I have a C++ based dynamic library that I have built for the big 3 OSs that relies heavily on boost. Currently, I am compiling it for the raspberry pi. It took me a while to find the magic words to get the library to even build (-frepo as a compiler flag was the key, but I confess that I am not certain why this is the case).
Now, when I try to link to the library, I get an 'undefined reference' error to every boost call that my library makes, i.e.:
//`libmylib.so`: undeifined reference to `boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr()'
When I build libmylib.so, I also build a custom version of boost as libboost.a. This all compiles and links fine on other OSs and non-ARM architectures so I tried putting -lboost as one of the flags, but I still get the same plethora of undefined reference errors form libmylib.so.
Needless to say, all my paths are correct.
It seems like linking behaves a bit differently on the raspberry pi than it does on other linux systems. For example, I built a static library (libmythread.a) that uses libpthread. When I link to that libmythread.a, I also get undefined reference errors unless I also use -lpthread in the build recipe. On my Thinkpad running Fedora, I would never have to do this since I included -lpthread in the compilation of the static library libmythread.a.
I would love to find a tutorial or guide that explains these discrepancies. I would also love to overcome them!
I also tried the same build on a conventional linux machine and everything linked fine, no problem. At least I know that my build process is OK. This does open up the possibility, though, that the -frepo flag is doing something funny that I don't understand and that this could be the root of the problem.
Solved. In the end, the trouble stemmed from the -frepo flag. This was necessary to compile a file called legacy_abi.cpp that is part of my library to allow third party developers using older and more exotic OSs/compilers. This isn't needed on the Pi, so I just removed it from the offending file from the build, dropped the -frepo flag and happy happy.
One final note, aptitude (for Pi, anyway) only supplies boost up to 1.49 (as far as I can tell). My project requires boost >= 1.50. This is an inherited project, so I'm still discovering all its little idiosyncracies.
I recently asked a question concerning embedding ruby in a c++ application
Embedding ruby in c++, problem with ruby libraries
Now I encountered another problem related to this. I managed to compile and run this application, but i can't link ruby statically. This is what my console says:
####:~/Desktop/rubyParser$ g++ -o ruby_test ruby_test.c -I/usr/lib/ruby/1.8/x86_64-linux/ -static -lruby1.8
/usr/bin/ld: cannot find -lruby1.8
But if I open /usr/bin, there is a "ruby1.8" file (no extension). Probably i need another file..
I'm using Ubuntu and I'm NOT a Linux expert of course, so please be patient with me :)
How can I fix it?
Thanks in advance
Bye
By specifying -lruby1.8 the linker will look for a file named libruby1.8.so in the standard library locations (probably /usr/lib/ or /usr/local/lib).
Take a look at those directories to see if you have something like that in there.
If not, have you installed the development package of ruby ? If only the linking process fails, I would assume you have (otherwise, it is likely that you wouldn't have the headers as well).
I never linked with ruby, but have you tried specifying -lruby instead of -lruby1.8 ?
Have you tried adding the binary to your PATH ?
You may need to, if you've recently installed the Ruby libraries in question, go to the command-line and type in sudo ldconfig to refresh ld's configuration files with the latest versions of your libraries and their locations.
Edit: From the comments below, you'll only need to-do this step if you run into a run-time linking problem, which you haven't at this point. But it's at least something to keep in-mind as it has solved run-time linking problems for me in the past (i.e., helped me with GMP).
I made a program on Mac OS X using OpenGL and dynamically linking libpng. I'm now trying to port it to Windows. Whenever I try to compile and link my ported program in Borland it gives me this error and about 10 more that are the same, but with a different '_png_create_read_struct':
Error: Unresolved external '_png_create_read_struct' reference from C:\PROGRAMMING\PNGTEST.OBJ
I assume it's because I have not properly set up libpng with Borland C++ 5.5.1 for Win32. I've put png.h and pngconf.h into the include folder into C:\Borland\BCC55\Include, and I have put libpng12.dll.a, libpng13.a, libpng13.dll.a, libpng.a, libpng.dll.a, libpng12.def, libpng.def, libpng12.la, and libpng.la into C:\Borland\BCC55\Lib (there is probably no need for them all, but as a noob I have no idea which ones are needed and not).
Do I need to put a libpng.obj file in there too? And if so how would I make/get one? I have tried using makefile.bc32 to set up libpng, yet that gives me a missing separator error.
Here are my command-line options:
bcc32 -tW pngtest.cpp -lpng
I include png.h in my code. What am I doing wrong or is there an even better way to load images with alpha that doesn't need libpng, or even a better compiler to get for Windows?
You're probably better off with the MinGW compiler than Borland. Borland is not well supported any longer.
You could also download DevC++ and see if it has a libpng package in its addon mechanism.
DevC++ is an IDE that uses the MinGW C/C++ compiler.
That said, if you feel you must use BCC, you'll either have to
a) Build libpng with Borland. This is the best solution if you're going to use borland.
b) Use, I think, Impdef to create an import library from libpng.dll. You'll find impdef.exe or imp(something).exe in the borland bin directory.
Note that some libraries will not work with impdef as there is static code linked to the dll that causes it to fail without the proper runtime.
First of all, I would not have "polluted" the BC55 installation with third-party libraries; it will make moving the project to other build environments much more difficult. It would have been better to place them in a folder within your project.
Secondly do you know that the export library you are attempting to link is built for BC55? The .a extension suggests a GNU library (Borland libraries conventionally use .lib extension), in which case it would not link with BC55 which uses a different object file format. If this is the case you will need to rebuild the library as you attempted to do, so I suggest that you should really be asking a question about the problem you had with doing just that. I wonder whether the makefile is written for Borland make or GNU make, since they have differing syntax?
The command line option -lpng might be correct for GCC (where it will link libpng.a), but is meaningless to BCC. The -l option merely passes the text that follows to the linker. The linker command line, requires that the complete name be passed, and if no extension is provided, .lib is added implicitly.
You should probably just use coff2omf to convert the library. The DLL files are almost certainly in "Microsoft" COFF format.
See COFF2OMF.EXE, the Import Library Conversion Tool.
Good afternoon all,
I'm trying to develop my first Qt application. I'm getting many errors like the following if I try to link in static libraries with my own code:
H:/NetBeansProjects/CommonLib/aes.cpp:607: undefined reference to `__gxx_personality_sj0'
H:/NetBeansProjects/CommonLib/aes.cpp:607: undefined reference to `_Unwind_SjLj_Register'
H:/NetBeansProjects/CommonLib/aes.cpp:615: undefined reference to `_Unwind_SjLj_Resume'
My code compiles and works when not used with Qt.
The Qt program compiled and worked before I tried to link my libraries.
Google-ing it shows it may be a mismatch between compilers used to build the two sets of code. I set the Netbeans environment to use the same tool chain to build both with no
change.
I'm using Windows, NetBeans 6.9.1, and the latest Qt. I've set the compiler to use
the Qt supplied mingw compiler.
Any suggestions?
Found the solution!
It was linking in libraries from previous versions of my projects.
I installed a new version of Mingw compiler with Qt to fix an issue. I set up the new compiler as a toolchain with a different name in Netbeans.
I did a clean and build on the referenced projects using the new tool chain. Netbeans stored the compiled library in a directory named from the tool chain. It left the old version of the library in another directory named for the original tool chain.
When you add a project reference to a library Netbeans imports the path to the library. If you change the tool chain (and therefore change the path to the library) other projects still point to the old code. You have to remove the project references and re-add them.
Recently I have asked a question about what I should use to create self-contained executables that would be deployed under a number of Linux distribution. I got very scared at first, but after reading about C++ a little, I managed to get the first version of my executable going.
After a day full of joy, I just hit the wall again with another dilemma. The resulting executable must be installed in a number of Linux distributions (Slackware, Arch, Ubuntu, Debian, CentOS and a few more), and I am completely clueless on how to achieve it. All I know CentOS and Debian-based OSes has package managers, like apt or yum, but I am not sure those apply to my case.
The code I wrote depends on a couple of libraries (more specifically RudeSocket and yaml-cpp. I have been told that I would be able to compile the executable and link it dynamically, so I just needed to distribute the executable.
It happens that I could not find the .a file for the yaml-cpp library (just for RudeSocket). And here's my problem so far:
At first, I went with dynamic linking but (obviously) when I copied the executable to another box:
$ ./main
./main: error while loading shared libraries: libyaml-cpp.so.0.2: cannot open shared object file: No such file or directory
When trying to compile it statically, I get an error too (because I don't have the yaml-cpp .a file as I mentioned):
$ g++ main.cpp parse.cpp parse.h rudesocket-1.3.0/.libs/librudesocket.a -o main -static -L/usr/local/librudesocket-1.3.0/.libs/librudesocket.a(socket_connect_normal.o): In function `rude::sckt::Socket_Connect_Normal::simpleConnect(int&, char const*, int)':
/root/webbyget/sockets/rudesocket-1.3.0/src/socket_connect_normal.cpp:250: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/tmp/cc3cEVK1.o: In function `operator>>(YAML::Node const&, Job&)':
parse.cpp:(.text+0x1a83): undefined reference to `YAML::Node::size() const'
/tmp/cc3cEVK1.o: In function `handle_job(rude::Socket, char const*)':
parse.cpp:(.text+0x1b79): undefined reference to `YAML::Parser::Parser(std::basic_istream<char, std::char_traits<char> >&)'
parse.cpp:(.text+0x1bfd): undefined reference to `YAML::Node::Node()'
parse.cpp:(.text+0x1c10): undefined reference to `YAML::Parser::GetNextDocument(YAML::Node&)'
parse.cpp:(.text+0x1dc6): undefined reference to `YAML::Node::size() const'
parse.cpp:(.text+0x1dee): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e18): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e37): undefined reference to `YAML::Parser::~Parser()'
parse.cpp:(.text+0x1e61): undefined reference to `YAML::Parser::~Parser()'
(...)
It's pretty obvious to me that g++ cannot compile it statically without telling it where to find the classes for yaml-cpp.
It is very important that the installation should happen without human interaction, in an automated fashion.
So my question is really twofold:
how can I distribute this compiled program in the least complex way targeting all those distributions?
is there any de facto standard solution for this kind of problem?
Thank you in advance,
Felipe.
You might give this technique a try.
There are many de-facto standards, but none of them are standardized. :( If you want to distribute a compiled binary, you will probably want to make a package for each platform you want to target. Generating an rpm and a deb will probably get you 90% of the way. If you want to automate the build process, autoconf/automake is still (probably) the best way to go.
Maybe The best solution for you is to use CMake.
CMake is cross-platform, open-source build system. It is a family of tools designed to build, test and package software. For Packaging, Mgb is right, CMake can easily be coupled with CPack.
KDE is using this solution and its a very good alternative to automake/autoconf.
If you use the platforms package manager (.rpm or .deb) the system will check for the correct version of the shared library for you and download it if it is needed.
CPack is probably the easiest package generator