Member Avatar for yottameter

I've run into linking problems before, so I thought I had them figured out. This one I'm using every tool I have, but I can't seem to identify what the issue is.

Did a build from the yaml site yesterday, I keep getting this linking error at runtime. I set LD_LIBRARY_PATH, but as you can see the shared object that is missing with ldd is in the path. Am I missing something here?

$ g++ -fPIC -Wall -lyaml-cpp main.c -L$YAMLCPP/yaml-cpp/build-I$YAMLCPP/yaml-cpp/include
$ a.out
a.out: error while loading shared libraries: libyaml-cpp.so.0.2: cannot open shared object file: No such file or directory
$ ldd a.out
        libyaml-cpp.so.0.2 => [B]not found[/B]
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000034ce400000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x00000034cbe00000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000034ce200000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x00000034cbb00000)
        /lib64/ld-linux-x86-64.so.2 (0x00000034cb700000)
$ ls $LD_LIBRARY_PATH
CMakeCache.txt       CTestTestfile.cmake  libyaml-cpp.so.0.2.4  yaml-cpp.pc
CMakeFiles           libyaml-cpp.so       Makefile              yaml-reader
cmake_install.cmake  [B]libyaml-cpp.so.0.2[/B]   util
  • 5 Contributors
  • 10 Replies
  • 240 Views
  • 3 Months Discussion Span
  • Latest Post Latest Post by Jason Butler

Dani AI

Generated

Final diagnosis and concise fixes (keeps the useful bits from the thread together)

@ybottameter’s final post correctly identifies the root cause: the LD_LIBRARY_PATH value was not exported from a tcsh session because it was created with set instead of setenv. In tcsh set creates a shell-only variable; setenv creates an environment variable that child processes (including the dynamic loader) can see. The library and symlinks, and file permissions, were already correct, so the problem was purely the variable not being visible to the program launcher.

Quick, practical commands and persistence

# tcsh (interactive/persistent in ~/.tcshrc)
setenv LD_LIBRARY_PATH /path/to/libs:$LD_LIBRARY_PATH

# bash (interactive/persistent in ~/.bashrc)
export LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH

# update system cache (requires root, suggested by @JasonButler)
sudo ldconfig

Other robust options and debug tips

  • Embed a runtime search path at link time to avoid relying on LD_LIBRARY_PATH: add a linker option such as -Wl,-rpath,/path/to/libs when linking.
  • For system-wide installs, add the lib directory to /etc/ld.so.conf.d/ and run sudo ldconfig.
  • Trace the dynamic loader to see where it looks with LD_DEBUG=libs ./a.out. Check runpath/rpath/SONAME with readelf -d a.out or readelf -d libyour.so | grep SONAME. Those checks complement ’s permission/size suggestion and the ldd output already posted.

Short checklist to close the loop

  • Confirm the variable is exported in the same shell that launches the program (env | grep LD_LIBRARY_PATH).
  • Verify ldd or LD_DEBUG=libs finds the shared object.
  • Use setenv in tcsh or export in sh/bash for persistence, or prefer rpath/system install for production.

This groups the thread’s findings (environment vs. file permissions) and gives immediate, repeatable steps for the same failure mode.

Recommended Answers

All 10 Replies

Member Avatar for lotrsimp12345

the actual code would be helpful not just the errors.

Member Avatar for WaltP

the actual code would be helpful not just the errors.

Why? "cannot open shared object file: No such file or directory
" has nothing to do with the code.

Member Avatar for thomas_naveen

Check the size of the library on disk and whether you have the necessary permissions to use it?

Member Avatar for yottameter

Yes, I didn't think the code was necessary in a linking problem. However, here it is if someone wants to download and build the latest yaml.

Here is the code in main.c

#include "yaml.h"
#include <iostream>
#include <fstream>

int main()
{
   std::ifstream fin("test.yaml");
   YAML::Parser parser(fin);
   YAML::Node doc;

   return 0;
}
Member Avatar for yottameter

Thanks for taking time to respond. Very good thought, I built it myself though. Here's the detailed ls:

ls -lart $LD_LIBRARY_PATH | grep ".so"
-rwxr-xr-x  1 me users 664546 Mar  7 16:48 libyaml-cpp.so.0.2.4
lrwxrwxrwx  1 me users     20 Mar  7 16:48 libyaml-cpp.so.0.2 -> libyaml-cpp.so.0.2.4
lrwxrwxrwx  1 me users     18 Mar  7 16:48 libyaml-cpp.so -> libyaml-cpp.so.0.2

Check the size of the library on disk and whether you have the necessary permissions to use it?

Member Avatar for thomas_naveen

Try setting the path too.

Member Avatar for yottameter

Used $ chmod ugo+rw -R yaml-cpp-0.2.4 still same result. I built the directories in my area to remove any doubt. In that directory I have other .so's loading. Could it be an error with the build? How would I troubleshoot that?

Try setting the path too.

Member Avatar for thomas_naveen

Have you set the path variable?

You can debug build by setting the verbosity.

Check your compiler documentation.

Member Avatar for yottameter

I had our network guy look into it. The problem was that the LD_LIBRARY_PATH was set in tcsh with 'set' as opposed to 'setenv'. This didn't allow the variable value to be propagated to the child process.

Member Avatar for Jason Butler

I had the same problem and solved it by running sudo ldconifg

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.