4 Replies Latest reply on Oct 18, 2018 2:40 AM by sjesse

    Horizon Client for Linux 4.9.0 fails to run due to undefined symbol

    Dominik Mierzejewski Novice

      The VMware Horizon Client for Linux version 4.9.0 fails to start with the following error on my machine:

      $ vmware-view
      /usr/lib/vmware/view/bin/vmware-view-crtbora: symbol lookup error: /usr/lib/vmware/libcrtbora.so: undefined symbol: _ZN4Glib7ustring5beginEv

      The missing symbol is:

      $ echo "_ZN4Glib7ustring5beginEv" | c++filt
      Glib::ustring::begin()

      My machine is running Fedora 28 and the glibmm library does provide the Glib::ustring::begin() symbol, but only through C++11 ABI:

      $ objdump -T /usr/lib64/libglibmm-2.4.so.1|grep _ZN4Glib7ustring.begin | awk '{ print $NF; }' | c++filt
      Glib::ustring::begin[abi:cxx11]()

      Is there any chance of getting this fixed in a newer version of the Horizon Client by providing a build for a recent Fedora release?

        • 1. Re: Horizon Client for Linux 4.9.0 fails to run due to undefined symbol
          sjesse Expert

          You would have to get them to support it first

           

          • The OpenSSL library is updated to version openssl-1.0.2o. For your convenience, the Horizon Client installer provided on the VMware Downloads site downloads and installs the library.
          • Horizon Client for Linux 4.9 has been tested and is supported on the following 32-bit operating systems if you use the installer provided by VMware:
            • Ubuntu 16.04
            • Red Hat Enterprise Linux (RHEL) 6.10
          • Horizon Client for Linux 4.9 has been tested and is supported on the following 64-bit operating systems if you use the installer provided by VMware:
            • Ubuntu x64 16.04 and 18.04
            • Red Hat Enterprise Linux (RHEL) 6.10 and 7.5
          • 2. Re: Horizon Client for Linux 4.9.0 fails to run due to undefined symbol
            Dominik Mierzejewski Novice

            Saying they support RHEL 7.5 is actually an overstatement. The client comes with a bunch of bundled libraries that are of different versions than the ones shipped with any of the distributions, including Fedora. It also uses dirty hacks to work with some system libraries with different SONAME, like libudev or libffi. Personally, I'm not installing all the bundled stuff that's in Fedora already and up to and including 4.8.0 it has been working on Fedora 27 and 28 beautifully without any issues. You can see my repackaging here. With 4.9.0, even if I do include all the bundled libraries, they are still overridden by system libraries, so it still fails to start, though in a different place.

             

            In my opinion, it would be best to build proper binary packages linked with libraries available on each supported distribution. I can help if VMware is listening. Of course, all this would be moot if only the client sources were released under an open license.

            • 3. Re: Horizon Client for Linux 4.9.0 fails to run due to undefined symbol
              Dominik Mierzejewski Novice

              The vmware-view-crtbora binary is very odd in 4.9.0. It seems to have STABS debug information:

              $ objdump -h vmware-view-crtbora |egrep '.stab|debug'
              29 .stab         0022044c  0000000000000000  0000000000000000  00301430  2**2
              30 .stabstr      006dfa75  0000000000000000  0000000000000000  0052187c  2**0
              32 .debug_aranges 000001c0  0000000000000000  0000000000000000  00c01360  2**4
              33 .debug_pubnames 0000007c  0000000000000000  0000000000000000  00c01520  2**0
              34 .debug_info   0000ec5f  0000000000000000  0000000000000000  00c0159c  2**0
              35 .debug_abbrev 00001709  0000000000000000  0000000000000000  00c101fb  2**0
              36 .debug_line   00002645  0000000000000000  0000000000000000  00c11904  2**0
              37 .debug_frame  00000088  0000000000000000  0000000000000000  00c13f50  2**3
              38 .debug_str    000028ac  0000000000000000  0000000000000000  00c13fd8  2**0
              39 .debug_loc    0000d052  0000000000000000  0000000000000000  00c16884  2**0
              40 .debug_ranges 00000ad0  0000000000000000  0000000000000000  00c238d6  2**0

              while the one in 4.8.0 has GNU debug information:

              $ objdump -h vmware-view-crtbora |egrep '.stab|debug'
              26 .gnu_debuglink 00000038  0000000000000000  0000000000000000  002fc2e8  2**2
              27 .gnu_debugdata 00010d78  0000000000000000  0000000000000000  002fc320  2**0

              I'm not sure it's relevant to the issue or not.

              Anyway, after patching the /usr/bin/vmware-view wrapper script to run vmware-view-crtbora only when it's actually installed instead everywhere except on ARM:

              --- vmware-horizon-client-4.9.0.9507999/vmware-horizon-client/bin/vmware-view.orig    2018-10-18 10:11:34.082958109 +0200
              +++ vmware-horizon-client-4.9.0.9507999/vmware-horizon-client/bin/vmware-view    2018-10-18 10:34:22.654390678 +0200
              @@ -23,7 +23,7 @@ else
              fi

              binFile=
              -if [[ $ROLLBACK_VMWAREVIEW = "" ]] && [ $cpu -eq 0 ]; then
              +if [[ $ROLLBACK_VMWAREVIEW = "" ]] && [ $cpu -eq 0 ] && [ -x "$binPath/bin/vmware-view-crtbora" ]; then
                  binFile="vmware-view-crtbora"
              else
                  binFile="vmware-view"


              the 4.9.0 client works without the Seamless Window Feature but otherwise fine on Fedora 28 using system libraries where available.

              • 4. Re: Horizon Client for Linux 4.9.0 fails to run due to undefined symbol
                sjesse Expert

                I get what your trying saying, but I think they only test the client on Ubuntu and Red hat, fedora and centos while similar are packaged different as you know. Trying to support every Linux distro is tough, which is why they stick with red-hat and Ubuntu as they are the most used commercially.. The same thing is true with the virtual desktops, they seem to only support Ubuntu and red hat, with the best support for red-hat.

                 

                Maybe someone else has seen this and has a suggestion, but I don't think you'll get to far with vmware themselves, you'll get the standard its not supported response