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?
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
You would have to get them to support it first
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.
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.
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
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?
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.
This still appears to be an issue with 5.1.0 as well. The patch from Dominik Mierzejewski got me up and running again.
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
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!
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)
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.