I am trying to link some propetary code on eLux 5 (works on eLux 4) a special Linux distribution.
The command line is very long and contains: -ludev -lpenDriverApi (both dynamic libraries, penDriverApi ist the propetary code which depends on udev).
Now the linker tolds me that various references are undefined from udev like 'udev_monitor_unref'. With "nm" I verified that these references are available within the udev shared object - so this error messages are really strange to me.
Because I also tried various verbose/debug settings for the linker I am now at a point without having a clou how to find out what went wrong during linking of my cmake project.
Hopefully this picture is readable, because the damned vmware would allow copy/paste which is enabled (maybe the elux config is bad).
udev Version on eLux 4 is 0.6.1
udev Version in eLux 5 is 1.3.5
The solution to this problem was, that the third party shared library libpenDriverApi.so required recompilation with a libudev.so.1 as well as a change to the linker, so that ldd -r also shows the dependency to libudev.
In the linkage sequence any object file or library that requires symbol
definitions must appear before the library that provides the definitions,
or undefined reference errors will ensure. This is because the
linker by default will search a library only to find definitions of
symbols that it has observed are referenced, but not defined, in earlier
files.
So if libpenDriverApi depends on libudev then you have to link in the order:
-lpenDriverApi -ludev
Related
I have a large Qt project under Ubuntu. Just found that G++ lets me compile AND link code where I'm calling an declared but undefined method. It crashes at runtime at that call.
I couldn't reproduce this behavior with a test project, although I enforced the same g++ command line.
The questions are:
why does it let me do that?
How can I make the linker generate an error?
Edits (based on the comments):
I know it's not optimized away, as it crashes at runtime when I call that method.
I declared and called another identical method with a dummy name - I think something along the lines of gfdsgfdhgasfdhgfa() will do :) - same thing.
The app crashes when the undefined method is called. Sorry for missing this important detail.
The undefined method is not a slot.
Yes, I'm clearing the build dir. I'm using qmake.
Just found there's an utility called nm. If I'm running it with the -u (show undefined only) option on the output .so I can see this method in the list. Why is GCC assuming it's external?
It looks like by default GCC (not only G++) assumes all undefined symbols are externals. Visual Studio doesn't.
Relevant question: Force GCC to notify about undefined references in shared libraries
--allow-shlib-undefined
--no-allow-shlib-undefined
Allows (the default) or disallows undefined symbols in shared
libraries (It is meant, in shared libraries _linked_against_, not the
one we're creating!--Pavel Shved). This switch is similar to --no-un-
defined except that it determines the behaviour when the undefined
symbols are in a shared library rather than a regular object file. It
does not affect how undefined symbols in regular object files are
handled.
The reason that --allow-shlib-undefined is the default is that the
shared library being specified at link time may not be the same as
the one that is available at load time, so the symbols might actually
be resolvable at load time. Plus there are some systems, (eg BeOS)
where undefined symbols in shared libraries is normal. (The kernel
patches them at load time to select which function is most appropri-
ate for the current architecture. This is used for example to dynam-
ically select an appropriate memset function). Apparently it is also
normal for HPPA shared libraries to have undefined symbols.
I built and installed the source code of spidermonkey, I want to link its library and its include folder with my C++ application, so I wrote this command on linux
g++ -I/home/SpiderMonkey/js-1.8.5/js/src/dist/include
-L/home/SpiderMonkey/js1.8.5/js/src/dist/lib -lmozjs185 helloworld.cpp -o
but it gives me undefined reference error, so what is the problem with this command:
the path which the src code was built in is home/SpiderMonkey/js1.8.5/src
and when I installed the src code, its libs and include folder exist now in usr/local/lib and usr/local/include/js respectively, so which path should I use in the command to compile my hellowrorld.cpp.
Also, I found 3 libraries with the same name but with different extension:
libname.so, libname.so.1.0, libname.so.1.0.0 and libname.a
which library should I use and what are the differences?
Put the libraries after your main.cpp on the compilation command. The linker determines which symbols to pull out of those libraries based on the objects it's already seen, left to right.
As for your addendum question:
libname.a is for static linking.
libname.so, libname.so.1.0 and libname.so.1.0.0 are all the same file, just with names that give you an increasing level of version information granularity.
Which to use is beyond the scope of this answer, but you can find plenty of information about that already existing on the web.
I'm using CodeBlocks (the latest version, I'm not sure what that is at the moment)
I'm trying to use fallahn's SFML Tiled map loader, and so far I've successfully statically linked SFML and included the map loader files in my source as well as added it to my search directories, however, I'm having trouble linking zlib (which the map loader uses)
I'm gonna go ahead and walk you through how I linked zlib because I'm not even sure which step I messed up on:
obviously, I went on over to http://zlib.net and grabbed the latest version (1.2.8)
I unzipped it to my desktop
I went into my project's build options and initially i thought "I'll just globally set up my search directories like before" (for SFML and the map loader, there was an 'include' and 'lib' folder, i put 'include' in the compiler search directory, and 'lib' in the linker search directory), except there were no folders named 'include' or 'lib' in the folder that i got from unzipping. This is where I simply included the whole folder I unzipped (I'm pretty sure that's terrible practice but I wasn't sure what else to do)
I compiled an example from the Map loader's source files, and got an error along the lines of 'undefined reference to inflate' on 4 different occasions. I already figured at this point that I made an error while linking, so that's when I took to google. Most answers were simply "add -lz" or "link libz"
Well, I don't know what "add -lz" means.. like at all, so I just linked "libz", then my compiler gave me the error "ld.exe cannot find -lz", which led me to the assumption that linking libz and adding -lz are the same thing.
Here are some things I don't understand at all, and if you can't explain what they are, please at least explain how to blindly do it:
1. Compiling a library
2. Anything to do with make files, I don't know what they are or what they do at all
3. Adding commands to the project command-line.
Build messages:
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:834: undefined reference to inflateInit2_'
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:843: undefined reference toinflate'
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:852: undefined reference to inflateEnd'
C:/Documents and Settings/Brenda/Desktop/sfml-tmxloader-master/src/MapLoaderPrivate.cpp:881: undefined reference toinflateEnd'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 10 seconds)
4 errors, 0 warnings (0 minutes, 10 seconds)
The issue is, that zlib doesn't provide binaries for MinGW directly, they only provide *.lib, *.def and *.dll files, but in order to link with MinGW/GCC, you'll need an *.a file.
Since zlib is a C library the ABI will be identical and thus you can "simply" convert it, for instance with the help of lib2a. While this should work, it might still be better to download the source code and build zlib yourself, since it ships with a CMake file, it's rather easy to build.
I'm adding two classes and libraries to a system, parent.so and child.so deriving from it.
The problem is when the program is loading child.so it cannot find parent's virtual function's definition from parent.so.
What happens,
nm -D child.so will gives something like (I just changed the names)
U _ZN12PARENT15virtualFunctionEv
The program will crash running
_handle = dlopen(filename, RTLD_NOW|RTLD_GLOBAL); //filename is child.so
it'll give an error with LD_DEBUG = libs
symbol lookup error: undefined symbol: _ZN12PARENT15virtualFunctionEv (fatal)
The thing I cannot explain is, I tried LD_DEBUG = symbols using GDB, when running dlopen, the log shows it tried to look up basically in all libaries in the system except parent.so, where the symbol is defined. But from libs log parent.so is already loaded and code is run, and it is at the same path of all other libraries.
......
27510: symbol=_ZN12PARENT15virtualFunctionEv; lookup in file=/lib/tls/libm.so.6
27510: symbol=_ZN12PARENT15virtualFunctionEv; lookup in file=/lib/tls/libc.so.6
27510: symbol=_ZN12PARENT15virtualFunctionEv; lookup in file=/lib/ld-linux.so.2
27510: child.so: error: symbol lookup error: undefined symbol: _ZN12PARENT15virtualFunctionEv(fatal)
How the program or system is managing which library to look for a symbol's definition?
I'm new to Linux, can anybody point me some directions to work on?
Thanks.
EDIT
The command used to generate parent.so file is
c++ -shared -o parent.so parent.o
Similar for child.so. Is any information missing for linking here? Looks like child is only including parent's header file.
EDIT2
After another test, calling
_handle = dlopen("parent.so", RTLD_NOW|RTLD_GLOBAL);
before the crashing line will solve the problem, which I think means originally parent.so was not loaded. But I'm still not very clear about the cause.
You need to tell the linker that your library libchild.so uses functionality in libparent.so. You do this when you are creating the child library:
g++ -shared -o libchild.so child_file1.o child_file2.o -Lparent_directory -lparent
Note that order is important. Specify the -lparent after all of your object files. You might also need to pass additional options to the linker via the -Wl option to g++.
That still might not be good enough. You might need to add the library that contains libparent.so to the LD_LIBRARY_PATH environment variable.
A couple of gotchas: If you aren't naming those libraries with a lib prefix you will confuse the linker big time. If you aren't compiling your source files with either -fPIC or -fpic you will not have relocatable objects.
Addendum
There's a big potential problem with libraries that depend on other libraries. Suppose you use version 1.5 of the parent package when your compile your child library source files. You manage to get past all of the library dependencies problems. You've specified that your libchild.so depends on libparent.so. Your stuff just works. That is until version 2.0 of the parent package comes out. Now your stuff breaks everywhere it's used, and you haven't changed one line of code.
The way to overcome this problem is to specify at the time you build your child library that the resultant shared library depends specifically on version 1.5 of libparent.so`.
To do this you will need to pass options from g++/gcc to the linker via the -Wl option. Use -Wl,<linker_option>,<linker_option>,... If those linker options need spaces you'll need to backslash-escape them in the command to g++. A couple of key options are -rpath and -soname. For example, -rpath=/path/to/lib,-soname=libparent.so.1.5.
Note very well: You need to use the -soname=libparent.so.1.5 option when you are building libparent.so. This is what lets the system denote that your libchild.so (version 1.0) depends on libparent.so (version 1.5). And you don't build libparent.so. You build libparent.so.1.5. What about libparent.so? That needs to exist to, but it should be a symbolic link to some numbered numbered version (preferably the most recent version) of libparent.so.
Now suppose non-backward compatible parent version 2.0 is compiled and built into a shiny new libparent.so.2.0 and libparent.so is symbolically linked to this shiny new version. An application that uses your clunky old libchild.so (version 1.0) will happily use the clunky old version of libparent.so instead of the shiny new one that breaks everything.
It looks like you're not telling the linker that child.so needs parent.so, use something like the following:
g++ -shared -o libparent.so parent.o
g++ -shared -o libchild.so -lparent child.o
When you build your main program, you have to tell the compiler that it links with those libraries; that way, when it starts, linux will load them for it.
Change their names to libparent.so and libchild.so.
Then compile with something like this:
g++ <your files and flags> -L<folder where the .so's are> -lparent -lchild
EDIT:
Maybe it would be a smaller change to try loading parent.so before child.so. Did you try that already?
I want to compile statically pdf2svg so I will be able to use newest version in stable Debian. The ./configure doesn't give --enable-static option so I added manually in Makefile -static option for linker.
Unfortunately the result wasn't quite as I suspected. The linking gave me enormous amounts of undefined reference errors. After some googling I figured out that the problem is caused by wrong order of -lsome_lib. Gcc linker tries to statically link in each library once, when it first sees it - info and Stackoverflow question: Why does the order in which libraries are linked sometimes cause errors in GCC?.
Is there a possibility of making linker make multiple passes through the list of libraries?
Maybe this is what you search for (from gnu ld manpage):
-( archives -)
--start-group archives --end-group
The archives should be a list of archive files. They may be either explicit file names, or -l options.
The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is
specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on
the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references
are resolved.
Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.
A tick is, whenever possible, to add a static reference to an object of the class (or to the function) that were not linked in another cpp file of the same library (or in another library already used).
I have this situation:
library A with class clsA in clsA.cpp that gives the error
library A with foo.cpp that gives no reference errors
library B that uses class clsA
Application uses both libraries and uses classes/functions from foo.cpp
I get the unresolved reference in Application while using the object in library B that uses the clsA class.
Linking Application with library A and B give me the error. Since i use CodeLite, it's hard to change library order. I simply put a static object in foo.cpp:
#include "clsA.h"
clsA objA;
The linker now see that clsA are referenced in library A (between foo.cpp) and will link correctly in application because foo.cpp were already linked.
But the trick works even if the object were created in a dummy function, never called, so the object would never been allocated:
// foo.cpp
#include "clsA.h"
void dummyf()
{
clsA objA;
}