On 06/07/2016 10:06 AM, Igor wrote:
in folder named myprogram where i hawe my program named testprog im create folder named proglib and copy all files from usr/lib to proglib folder.
I assume that since you are referring to these as 'folders' you background is in Windows rather that UNIX/Linux. So there are probably a lot of assumptions you are making that are fine in Windows but make no sense for Linux, and Linux assumptions that you aren't aware of that are tripping you up. Search paths seem to be one of them. My first reaction to the above was "Why did you do that? It makes no sense". But I see from the following ..
In folder myprogram its program named testprog. In conzole i wride export LD_LIBRARY_PATH="/home/igor/my program/proglib/" and command echo $LD_LIBRARY_PATH get me result /home/igor/my program/proglib/
.. that you don't understand search paths. The docco in the pages you were advised to search for probably mentioned something like Multiple directories can be listed, separated with a colon (:). !THIS IS IMPORTANT! There's another assumption. If that is not set then the loader assumes the defaults. What you've done is told it to ignore the defaults altogether and only use that one directory to look for libraries. The only reason you don't have a massive cascading set of failure is that you've copied all the other libraries there as well, which, as I said, in the context of Linux makes no sense. The purpose of LD_LIBRARY_PATH is to tell the loader about *all* the the libraries, listing them separated with a colon. What you want is something like export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:\ ~/my\ program/proglib:\ /usr/lib64:\ /usr/lib I've broken that up with line continuing (the "\" and tabing) to make it readable. You don't want to copy-paste as is, you;ll want to make it into one line line, but I type that I'll get line wrap which is also confusing. So get rid of the extra copy of the the library you made, its not needed if you use LD_LIBRARY_PATH properly. Linux can be very minimal compared to Windows. The next thing to tell is is if libQt5PrintSupport.so.5 and libQt5PrintSupport.so.5.6 are linked. After that, what you should do is take a look a what's in your executable, what its library requirement and dependences actually are. I don't know if Windows has anything like this, but in Linux there is the "ldd" program. As the man page says, it can be used with LD_LIBRARY_PATH to determine where the needed libraries are - or aren't For example $ ldd /bin/bash linux-vdso.so.1 (0x00007fff9e9c6000) libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fbf79400000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fbf791cc000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbf78fc8000) libc.so.6 => /lib64/libc.so.6 (0x00007fbf78c1a000) /lib64/ld-linux-x86-64.so.2 (0x00007fbf79648000) Don't worry about 'vdso', its just a thing that gets included in the C library to deal with optimising repeated systems calls. All programs have it. The next three lines, the ones with the "=>", are a result of the dynamic linking with the (often implied) libraries on the search path specified by LD_LIBRARY_PATH You'll note that most of the binary programs in /bin and /usr/bin are quite economical in their use of libraries. BASH is a very capable program, but as you can see above, it uses very few libraries. It's not until you get to the graphics programs in /usr/bin/X11 do you see programs with many libraries. You should get used to reading man pages. Failing to do is crippling. You can use the 'apropos' tool to find related man pages. Try "man apropos" to start with, then "apropos loader". That will give you a lot of stuff and you should recognise that much of it is not related to loading programs, but 3 items *are* of relevance to what you are dealing with ld-linux (8) - dynamic linker/loader ld-linux.so (8) - dynamic linker/loader ld.so (8) - dynamic linker/loader That indicates that the pages are in section 8 of the overall manual, so you'd use the specific man 8 ld.so to read the last one. In many cases, this is one specify the section isn't needed, but in others you may need to differentiate between, say, a system call and a library function or a a tool. Again, that's where 'apropos' comes in useful :-) No-one claims the man pages are well written. They are written by programmers rather than professional documentation writers. But they are remarkably complete. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org