Linux C++ LD_LIBRARY_PATH suppressing standard libraries

Question

I'm kind of new to C++ although I have done some Objective C recently so some of it looks vaguely familiar.

I'm in the process of writing some test programs to gauge whether something is going to be possible or not. In my (very simple 'Hello World') program I'm outputting some text using cout which works fine, however when I modify the LD_LIBRARY_PATH to point to some libraries required by a 3rd party application that I'll be communicating with I get no output but no compiler errors from g++.

I've tried including the standard paths e.g. /usr/local/lib:/usr/lib:/lib but when I include this in the path I still get no output.

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello World";
    return 0;
}

As you can see it a pretty simple program at the moment which works as expected before I set the LD_LIBRARY_PATH.

I'm not getting any errors at all at any stage so I've no way of knowing whether it's running. Is there anything I can check or any way for me to test whether the program is even running?

P.S. I've also tried writing output to a file which works before setting the path.

Many thanks

UPDATE

Thanks for the replies (see comment below for results)

Based on what @Nemo said about the 3rd party app having it's own version of libstdc++.so, which was correct, I've swapped out their version of that library with the standard install version. Although I am now getting the 'Hello World' output I am still receiving numerous No such file or directory errors when strace'ing the program so I'm guessing the issue is only partly fixed. I'm not sure if what I've done is 'allowed' or how to proceed from here.

Try adding endl; on the end of your line, to ensure that the problem isn't just that cout is not flushing the output. — Mats Petersson
LD_LIBRARY_PATH has nothing to do with C++, it has to do with ld.so - and it should not override the system libraries unless the same library can be found in your LD_LIBRARY_PATH. Please can you show us the exact commands used to compile and the exact commands used to run. Also try running something like strace -f _binary_ - and check output - you should see what is happening from that — Iwan Aucamp
@Iwan: He said the LD_LIBRARY_PATH setting is required by a "third-party application". In my experience, those often ship with their own version of libstdc++.so (the C++ runtime). I highly suspect this is the source of the problem. — Nemo
@user761389 - can you maybe give us the list of files in the path you added to LD_LIBRARY_PATH - and also run ldd on your binary with the ld library path set and attach the output. — Iwan Aucamp
Run ldd yourprogram with and without LD_LIBRARY_PATH set. Is there a difference in the output? — n. 1.8e9-where's-my-share m.

Homer6 Homer6 · Accepted Answer · 2013-07-23T22:07:49

If you run:

ldd a.out

where a.out is the name of your executable, it will print the runtime shared library dependencies for that executable (see http://linux.die.net/man/1/ldd )

Here is an example output:

linux-vdso.so.1 =>  (0x00007fff463ff000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f75f6979000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75f65ba000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f75f62bd000)
/lib64/ld-linux-x86-64.so.2 (0x00007f75f6c85000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f75f60a7000)

Now, once you know what your application is searching for, you have to know that it's searching for it in the LD cache (or, the dynamic linker cache). That is typically stored at /etc/ld.so.cache. However, you shouldn't edit it manually. Instead, you should use ldconfig to regenerate that cache.

You can use:

ldconfig -p

To show all of the cache entries.

When you run

ldconfig

(as root), you'll regenerate the ldcache. The '/lib' and '/usr/lib' directories, and any listed in the file '/etc/ld.so.conf' are scanned by default unless `-n' is used. Additional directories may be specified on the command line.

When an executable is invoked, it will also check the paths in LD_LIBRARY_PATH (in addition to the ldcache) for any files listed in the ldd output.

So, what you can do is run:

ls -lah

on each of the files listed in the ldd output for your exectuable. If any of the files are missing, you will have to replace them with the appropriate shared libraries (*.so) in the /usr/lib or such directory and regenerate the ldcache. Once the cache has been generated, they should show up in the ldconfig -p output.

If you want to add new paths to be included in the ldconfig ldcache generation, you can add them to the /etc/ld.so.conf file. Then, the next time that the ldcache is generated, it will search in those directories for your shared objects. You could also put them in /lib or /usr/lib directories. I'd recommend not doing that. Instead, I'd recommend using the /usr/local/lib directory. It's usually in the ldcache path and is intended to be used with user-generated shared libraries.

Hope that helps

See: http://linux.die.net/man/8/ldconfig

See: http://linux.die.net/man/1/ldd

Lastly, the "locate" command is useful for finding files in any path. It uses a database that is frequently updated, so if the file has been there for a while, it's probably in the locate database.

You can search for a file like this:

locate libstdc++.so.6

If the file has recently been added to a path and is not in the locate database, you can run updatedb to regenerate the locate database. Then, you should be able to find any file on your filesystem.

For more information surrounding this topic, I'd recommend reading this book: http://www.network-theory.co.uk/docs/gccintro/

Linux C++ LD_LIBRARY_PATH suppressing standard libraries

UPDATE

1 Answers