VMware Horizon Community
dm27408
Enthusiast
Enthusiast
Jump to solution

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

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 Solution

Accepted Solutions
dm27408
Enthusiast
Enthusiast
Jump to solution

With 5.2 the patch is not needed anymore. Actually, it was needed only if one didn't want to install the Seamless Window feature. Regardless, you only have to put the following libraries from vmware-horizon-pcoip/pcoip/lib/vmware/ into /usr/lib/vmware and the vmware-view-crtbora binary (or the main vmware-view) in 5.2 works fine:

libatkmm-1.6.so.1
libgdkmm-3.0.so.1
libgiomm-2.4.so.1
libglibmm-2.4.so.1
libgtkmm-3.0.so.1
libpangomm-1.4.so.1

View solution in original post

11 Replies
sjesse
Leadership
Leadership
Jump to solution

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
Reply
0 Kudos
dm27408
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
dm27408
Enthusiast
Enthusiast
Jump to solution

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.

sjesse
Leadership
Leadership
Jump to solution

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

Reply
0 Kudos
LaszloaToth
Contributor
Contributor
Jump to solution

Hi All,

First let me pin down that I had the same question but Dominik gave me valuable head ups on Horozon 4.9.0 install on Ubuntu LTS 18.04

Actually the client is working, but the connection is not stable. Let me ask you about the reason is server/client related.

The first errors mean dbus proxy and usb control started but failed. Is it the source of the problem?

2019-01-01-104028_1440x346_scrot.png

2019-01-01-104152_642x575_scrot.png

Reply
0 Kudos
wlawrht
Contributor
Contributor
Jump to solution

I ran into the exact same issue. It appears that vmware-view is not linked correctly is still trying to used system libraries instead of the ones bundled with the application. You can get around this by manually specifying the location of the libraries:

$ LD_LIBRARY_PATH=/usr/lib/vmware /usr/lib/vmware/view/bin/vmware-view

Additionally, you can edit the ".desktop" file so that you can run Horizon from Gnome so that it uses the above environment variable. To do this, open the *.desktop with superuser permissions:

$ sudo nano /usr/share/applications/vmware-view.desktop

Find the line that begins with "Exec" and replace it with the following:

Exec=env LD_LIBRARY_PATH=/usr/lib/vmware /usr/lib/vmware/view/bin/vmware-view %u

Hit Ctrl+X to save (confirm with Yes if necessary). Now you should be able to open VMWare Horizon from Gnome.

Reply
0 Kudos
luxturbo
Contributor
Contributor
Jump to solution

This still appears to be an issue with 5.1.0 as well. The patch from Dominik Mierzejewski got me up and running again.

Reply
0 Kudos
dm27408
Enthusiast
Enthusiast
Jump to solution

With 5.2 the patch is not needed anymore. Actually, it was needed only if one didn't want to install the Seamless Window feature. Regardless, you only have to put the following libraries from vmware-horizon-pcoip/pcoip/lib/vmware/ into /usr/lib/vmware and the vmware-view-crtbora binary (or the main vmware-view) in 5.2 works fine:

libatkmm-1.6.so.1
libgdkmm-3.0.so.1
libgiomm-2.4.so.1
libglibmm-2.4.so.1
libgtkmm-3.0.so.1
libpangomm-1.4.so.1
luxturbo
Contributor
Contributor
Jump to solution

You are correct, installed 5.2 and no issues running it. Glad this is fixed, orginally I had created a bash alias to launch the client

alias vmware='LD_LIBRARY_PATH=/usr/lib/vmware nohup /usr/lib/vmware/view/bin/vmware-view &'

then you patch removed the need for the alias (though it wasn't much of an issue to begin with), now I can simply launch the thing.

Thanks for the follow up!

Reply
0 Kudos
reginolda
Contributor
Contributor
Jump to solution

Hi All,

I am trying to install VMware horizon and it was installed successfully. However when I tried to open VMware I get the below error. Any ideas?

[root@localhost lib]# vmware-view %u

vmware-view: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by vmware-view)

vmware-view: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /usr/lib/vmware/libcrtbora.so)

vmware-view: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/lib/vmware/libcrtbora.so)

Reply
0 Kudos
dm27408
Enthusiast
Enthusiast
Jump to solution

Which distribution are you running this on? I think the above happens only on RHEL 7 and similar, so you need to add the bundled libstdc++.so.6, too.

Reply
0 Kudos