libxml2.so.2: no version information available with GPDB 4.3.11.3 on CentOS 6.7

[kad...@pivotal.io]

Hi,

So I thought that this was a RHEL/CentOS 7 thing only.  Customer sees this message on CentOS 6.7 as well. As user gpadmin, having sourced greenplum_path.sh, running various OS commands generates this informational message: 

[gpadmin@dcb00slm0003 ~]$ nslookup coke.com

nslookup: /usr/local/greenplum-db/./lib/libxml2.so.2: no version information available (required by /usr/lib64/libisc.so.83)

Server:        127.0.0.1

I get that there might be workarounds (stackoverflow <dot> com/questions/137773/what-does-the-no-version-information-available-error-from-linux-dynamic-linker)

Just curious what should be done about it on a v3DCA running GPDB 4.3.11.3 on RHEL 6.7 (Santiago), 2.6.32-573.22.1.el6.x86_64.  Anything? Nothing? Just explain to the customer that this message is harmless and to ignore it?  That would be my guess.... just wondering if there is a better answer.

[root@dcb00slm0003 ~]# find / -name libxml2.so.2 -print

/usr/lib64/libxml2.so.2

/usr/local/GP-4.3.11.3/lib/libxml2.so.2

Should we also be building and including our own libisc.so.83 file as well?

[root@dcb00slm0003 ~]# find / -name libisc.so.83 -print

/usr/lib64/libisc.so.83

Thanks.

[jzh...@pivotal.io]

Don't source greenplum_path.sh

[David Sharp]

The problem here of course is that greenplum_path.sh sets LD_LIBRARY_PATH, which means that .so's meant for gpdb also are found when running non-gpdb binaries.

Not sure what the 100% correct solution is, but one solution may be:

- Remove LD_LIBRARY_PATH from greenplum_path.sh

- Move gpdb binaries to another directory not on PATH ($prefix/libexec?)

- In $prefix/bin, for each real binary, symlink to a wrapper script that sets LD_LIBRARY_PATH before exec'ing the real binary.

- The wrapper script can use $0 to find the real binary.

d#

[Ning Yu]

Is it possible to use $ORIGIN in rpath? An example:

```

$ mkdir base

$ cd base

$ mkdir bin lib

$ echo "main(){}" > main.c

$ gcc main.c -o bin/main -Wl,-rpath,'$ORIGIN/../lib' -lxml2

$ ldd bin/main | grep libxml2

        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f99a11dc000)

$ cp -a /lib64/libxml2.so* lib/

$ ldd bin/main | grep libxml2

        libxml2.so.2 => /tmp/base/bin/../lib/libxml2.so.2 (0x00007fc1d0622000)

$ cd ..

$ mv base newbase

$ cd newbase

$ ldd bin/main | grep libxml2

        libxml2.so.2 => /tmp/newbase/bin/../lib/libxml2.so.2 (0x00007f4c891fa000)

```

In short the program main lookup libxml2.so first in the dir ../lib before system default paths, so in our case we could let gpdb find our own version of libxml2.so w/o the use of LD_LIBRARY_PATH.

However I don't know whether $ORIGIN is supported on old compilers, so this might not be an acceptable answer.

BTW, here is the description in `man ld.so`

```

   Rpath token expansion

       ld.so understands certain strings in an rpath specification (DT_RPATH or DT_RUNPATH); those

       strings are substituted as follows

       $ORIGIN (or equivalently ${ORIGIN})

              This expands to the directory  containing  the  application  executable.   Thus,  an

              application located in somedir/app could be compiled with

                  gcc -Wl,-rpath,'$ORIGIN/../lib'

              so that it finds an associated shared library in somedir/lib no matter where somedir

              is located in the directory hierarchy.  This facilitates the creation of  "turn-key"

              applications  that  do  not  need  to be installed into special directories, but can

              instead be unpacked into any directory and still find their own shared libraries.

       $LIB (or equivalently ${LIB})

              This expands to lib or lib64 depending on the  architecture  (e.g.,  on  x86-64,  it

              expands to lib64 and on x86-32, it expands to lib).

       $PLATFORM (or equivalently ${PLATFORM})

              This  expands  to  a  string  corresponding to the processor type of the host system

              (e.g., "x86_64").  On some architectures, the Linux kernel doesn't provide  a  plat‐

              form  string  to  the  dynamic  linker.   The value of this string is taken from the

              AT_PLATFORM value in the auxiliary vector (see getauxval(3)).

```

[Jasper Li]

$ORIGIN +1

Best wishes

Jasper

--