using usr defined libraries

[shumi12321]

I'm trying to create executable file which will run on several Linux platforms (without recompiling) so what I want is to copy dependent .so files to other machine along with executable.

I did

$ldd ./myapp
linux-vdso.so.1 =>  (0x00007fff8c5ff000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003c03400000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003bf3600000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003bf3200000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003bf2e00000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c01c00000)

and tried to copy those .so files to same folder as ./myapp, but whe ni do that, ./myapp doesn't load copied .so files but same ones as above (ldd gives same output).

How can I force ./myapp to use shared libraries I want?

Ty,
shumi12321

[rabinnh]

You typically don't have to copy the shared libraries to the target system. If you compile a 32 bit executable, you should find that it will run on most modern 32 bit distros. The same with 64 bit executables.

I personally compile a number of 32 bit executables that run without any problem on Centos 5, Debian 5, Debian 6, Ubuntu 8.04-10.10, and other distros without any changes. If you compile against (for example) libstdc++.so.6, your binary should run on any system that has any version of libstdc++.so.6. If you look in /usr/lib, you will see that the shared libraries are symlinks to specific versions of the same base release. On my system libstdc++.so.6 links to libstdc++.so.6.0.14.

So unless you plan on your program running on really old systems, don't worry about the shared libraries.

[BrianMicek]

Hi shumi12321,
Before I go on, rabinnh is right ... its a bad idea to copy shared libraries from one system to another. If you really want to do this, you can use the LD_LIBRARY_PATH env variable to specify the location as long as your not running your application as root. Other less popular ways to do this involve editing /etc/ld.so.conf (or something in /etc/ld.so.conf.d/ if you have one) and then manually invoking /sbin/ldconfig as root. Note this is a system wide change.

To learn more, do a "man ld" and its a good idea to set the variable to a complete path rather than a relative path (like "." for instance).

[shumi12321]

Can someone tell me about GTK+ files and their portability amongst Linux distros?

Are those libraries compatible since many distros make changes to their Gnome Desktop environment?

Ty,
shumi12321

[Irithori]

Probably not what you want to hear, but:
From my sysadmin point of view I would hesitate -if not flat out refuse- to install a software, that is packaged like this.

Yes, also big companys do it (I am looking at you, Symantec NetBackup), but that doesnt make it better.
- The installation will break the fhs.
- You need to be very careful about the environmnet, or ýou might end up loading system libs
- The installation is needlesly bloated
- The application is not covered by the native package manager

- Most likely, the added libraries will be left to rot.
They will get little to no maintenance despite new versions, new features, bugfixes, etc


So my advice would be to build native packages for the platforms you want to support.
And -if that is a open source app and you intend to do so- maybe leave the source at the usual places, so people can pick it up and package/install it themselves.

[BrianMicek]

shumi12321,
I just re-read your post and forgot to mention something. If your creating your own executable, I'm assuming your compiling it. If your using gcc or g++, you might be able to use "-static" for your compile and link flags.