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

[marc1uk]

There’s nothing modern here. I have the choice of ROOT 5.28 or ROOT 5.34.
I get the same error with both versions.

[pcanal]

humm what does

ldd `which root.exe`

prints?

[marc1uk]

moflaher@sukap001:~$ ldd `which root.exe`
	linux-vdso.so.1 =>  (0x00007ffd1a5d1000)
	libCore.so => /home/skofl/sklib_gcc4.8.5/root_v5.28.00h/lib/libCore.so (0x00007f3b57c9c000)
	libCint.so => /home/skofl/sklib_gcc4.8.5/root_v5.28.00h/lib/libCint.so (0x00007f3b57322000)
	libMathCore.so => /home/skofl/sklib_gcc4.8.5/root_v5.28.00h/lib/libMathCore.so (0x00007f3b56f1d000)
	libRint.so => /home/skofl/sklib_gcc4.8.5/root_v5.28.00h/lib/libRint.so (0x00007f3b56ce9000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f3b56aca000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f3b567c1000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f3b564bf000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3b562a8000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3b5608c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f3b55ccb000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f3b55ab4000)
	libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f3b5588d000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f3b55663000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f3b55401000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f3b551ca000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3b58603000)
	libfreebl3.so => /lib64/libfreebl3.so (0x00007f3b54fc6000)

[pcanal]

And what about:

nm -A /home/moflaher/skrootlibs/libatmpdroot.so | grep ' U ' | wc
nm -A /home/moflaher/skrootlibs/libatmpdroot.so | grep ' U ' | grep TObject | wc

I.e. I suspect that those libraries where not built with explicit linking and thus ldd can not help us in tracking down the missing component.

[marc1uk]

$ nm -A /home/moflaher/skrootlibs/libatmpdroot.so | grep ' U ' | wc
    127     381   11121
$ nm -A /home/moflaher/skrootlibs/libatmpdroot.so | grep ' U ' | grep TObject | wc
     50     150    4398

I have to admit this is beginning to reach my limits. I did do a nm libatmpdroot.so before and from the best of my ability to tell the class AtmpdInfo seemed to be defined within it, yet doing:
root [0] AtmpdInfo* atmpd = new AtmpdInfo() elicits the error under discussion, even though there is a rootmap file in my LD_LIBRARY_PATH that should pull in the appropriate library for the class definition. (The class name is highlighted by ROOT, suggesting it has some awareness of the class, and this method works fine on another system setup that ought to be equivalent.)

[pcanal]

@marc1uk

elicits the error under discussion,

Good at least that is consistent There is a problem with loading the library, we just don’t know what yet.

[Axel]

@pcanal the error message seems wrong, shouldn’t TSystem print the library name instead of ]?

[pcanal]

Sure … it is v5.[23]x … so yes issues

[pcanal]

@marc1uk So this library does depend and use ROOT. You earlier mentioned trying with 2 different version of ROOT. Please note that version of ROOT (and C++ libraries in general) are not interchangeable. You must use the same version of ROOT as the one use to build the library.

So which version of ROOT did you use when building the libraries? And from the build system of skrootlibs can you tell which libraries libatmpdroot.so depends on?

[pcanal]

Another things to look into is the rootmap files, does all the library listed in the rootmap files exists? Can any of them be loaded by gSystem->Load ?

[marc1uk]

I wasn’t the one who compiled the atmpdroot.so, but I’m fairly confident it was compiled with ROOT 5.28. As I mentioned before, there are 2 versions available, but the library doesn’t seem to load with either.
As for which libraries libatmpdroot.so depends on, that’s a tougher question to answer - the build system is rather complicated and a lot of the build process is obfuscated behind generic makefile rules. That said, the libatmpdroot.so appears to be built from a source file that simply contains:

#include "atmpdroot.h"
ClassImp(AtmpdInfo)
ClassImp(UpmuInfo)

with corresponding header files that define the classes AtmpdInfo and UpmuInfo as extremely simple classes that each encapsulate a single integer, an array of 255 integers, and a Clear method to set the array contents to 0. So I would guess that in fact there are no further dependencies…

[marc1uk]

Ah, I believe I’ve found it. A rogue ROOT 6 rootmap file, in another path on the LD_LIBRARY_PATH, seems to have been throwing a spanner in the works. it looks like somehow having that present caused the problem. A bit strange that this file is also present on the other system which doesn’t exhibit the behaviour.

Thanks for the support, sorry this turned out to be a rather dumb user error!

[marc1uk]

Of 26 classes defined in that rootmap file, the classes from all of them except libatmpdroot.so seem to be unperturbed by the presence of the rogue Rootmap file - which defines all the same 26 classes. Perhaps it’s because AtmpdInfo is the first defined, that something about it gets messed up before ROOT 5.28 aborts the parsing.