Error in <TUnixSystem::DynamicPathName>: ][.so | .sl | .dl | .a | .dll] does not exist in /path/ ... but it does!


ROOT Version: 5.28
Platform: linux (CENTOS-7)
Compiler: gcc 4.8.5


Hi ROOTers.
I’m trying to load a library that contains the definition of some custom classes.

root [0] gSystem->Load("/path/to/my/library.so")
Error in <TUnixSystem::DynamicPathName>: ][.so | .sl | .dl | .a | .dll] does not exist in /a/list/of/paths
(int)(-1)

However, the file I’m trying to load most definitely exists, and its location is in the list of paths printed by the error (i’ve added the path to my LD_LIBRARY_PATH, as well as trying to load via an absolute filepath).
There are actually several libraries in that same directory, defining a variety of classes, and some of them work while others don’t. They’re all compiled as part of the same (long and complicated) procedure, and are shared by a wide collaboration (SuperK) so can be assumed to be correct.

Can anyone make any suggestions why some are giving these errors, or how to debug this?

What do you get from: ls -al /path/to/my/library.so

lrwxrwxrwx 1 <my_username> sk     25 Nov 21 02:51 libraryname.so -> skofl_lib/librarynameso

Presumed to be unimportant, file I’m trying to load is a symlink to the true file elsewhere. The symlink appears to be fine.

ls -alL /path/to/my/library.so

moflaher@sukap001:~/skrootlibs$ ls -alL $PWD/libatmpdroot.so  
-rwxr-xr-x 1 moflaher sk 201906 Nov 21 02:03 /home/moflaher/skrootlibs/libatmpdroot.so

Try: gSystem->Load("/home/moflaher/skrootlibs/libatmpdroot.so")

It’s the same thing, i just didn’t bother editing the path names this time. :slight_smile: Same error.

moflaher@sukap001:~/skrootlibs$ root
root [0] gSystem->Load("/home/moflaher/skrootlibs/libatmpdroot.so")
Error in <TUnixSystem::DynamicPathName>: ][.so | .sl | .dl | .a | .dll] does not exist in /home/moflaher/skrootlibs/skofl_lib:/home/moflaher/relic_sk4_ana/relic_sk4_ana/data_reduc/third/lib:/home/moflaher/stllibs:/home/moflaher/skrootlibs:/usr/local/sklib_gcc4.8.5/root_v5.28.00h/lib:/home/moflaher/skofl/skofl/lib:/home/skofl/sklib_gcc4.8.5/skofl_19b/lib:/usr/local/lib:.:/usr/local/sklib_gcc4.8.5/root_v5.28.00h/lib::/usr/local/sklib_gcc4.8.5/root_v5.28.00h/lib/cint/cint/stl
(int)(-1)

notably /home/moflaher/skrootlibs is there in that list.

You specify the full path to the library so the “list” should not matter at all.

Good to know. Then could the error be a misnomer - could it be finding the file, but just not liking it for some reason? Although, as I say, this library is part of the standard libraries used by the whole collaboration, so i’m sceptical that it’s somehow corrupt.

I don’t have any good idea now.
In cases when the library exists but it cannot be loaded, I would expect: “Load Error: Failed to load Dynamic link library ...

How about: ldd /home/moflaher/skrootlibs/libatmpdroot.so

yeah, the error would be a bit misleading if that were the problem.

moflaher@sukap001:~/skrootlibs$ ldd /home/moflaher/skrootlibs/libatmpdroot.so
	linux-vdso.so.1 =>  (0x00007ffc9f51a000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f9f0ab23000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f9f0a820000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9f0a60a000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9f0a3ee000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f9f0a02c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9f0b054000)

Can it be that you have several different ROOT binaries visible in your “PATH” and “LD_LIBRARY_PATH” (e.g., in “/usr”, “/usr/local”, “/home/moflaher/skofl/skofl” and then in “/usr/local/sklib_gcc4.8.5/root_v5.28.00h”)?

No, there’s just one system ROOT installation

One “system ROOT installation” means “/usr/local/sklib_gcc4.8.5/root_v5.28.00h”?

I double checked, there are other ROOT versions, but none that my environment is set up to use.

Double-check the “LD_LIBRARY_PATH” (some ROOT libraries from another version may interfere).

I can’t see anything related to either the libraries I’m trying to load, or related to ROOT.

Maybe @Axel or @pcanal have some idea.

According to the “ldd” output, this library does not depend on ROOT libraries. So, try to load it with another (“modern”) ROOT version.