The new ebuild for app-emulation/vmware-workstation-12.1.0.3272444-r2 in the overlay is resulting in a segfault on startup of vmware-workstation. The same version number in ::gentoo works fine. Apr 03 12:49:23 harrisl-desktop systemd[1]: Started /opt/vmware/bin/vmware. Apr 03 12:49:23 harrisl-desktop kernel: vmware[8363]: segfault at 1290 ip 0000000000001290 sp 00007ffc0a769808 error 14 in appLoader[563d75f65000+ad000] these are the useflag settings: USE (bundled-libs) (cups) (-doc) (-ovftool) (-server) (-vix) (vmware-tools) BTW, I am running gnome-3.20 This is a diff of the gentoo vs vmware-overlay ebuilds: pkg_meta_diff vmware-workstation --- /var/db/pkg/app-emulation/vmware-workstation-12.1.0.3272444-r2/vmware-workstation-12.1.0.3272444-r2.ebuild 2016-04-03 12:51:46.861201021 -0400 +++ /var/paludis/repositories/vmware/app-emulation/vmware-workstation/vmware-workstation-12.1.0.3272444-r2.ebuild 2016-04-03 09:51:09.891327537 -0400 @@ -88,7 +88,6 @@ " BUNDLED_LIB_DEPENDS=" - app-accessibility/at-spi2-core dev-cpp/atkmm dev-cpp/cairomm dev-cpp/glibmm:2 @@ -96,19 +95,15 @@ dev-cpp/pangomm dev-libs/atk dev-libs/glib:2 - dev-libs/libaio dev-libs/libgcrypt:11/11 dev-libs/libgpg-error dev-libs/libsigc++:2 dev-libs/libxml2 dev-libs/openssl:0 - gnome-base/librsvg:2 media-libs/fontconfig media-libs/freetype media-libs/libpng:1.2 net-misc/curl - sys-apps/dbus - sys-apps/pcsc-lite sys-fs/fuse sys-libs/zlib x11-libs/cairo @@ -116,63 +111,31 @@ x11-libs/gtk+:2 x11-libs/libXau x11-libs/libXcomposite - x11-libs/libXcursor x11-libs/libXdamage - x11-libs/libXdmcp x11-libs/libXfixes - x11-libs/libXft - x11-libs/libXinerama x11-libs/libXrandr x11-libs/libXrender x11-libs/pango - x11-libs/pangox-compat x11-libs/pixman " # vmware should not use virtual/libc as this is a # precompiled binary package thats linked to glibc. RDEPEND=" - app-arch/bzip2 - dev-libs/dbus-glib - dev-libs/expat - dev-libs/gmp:0 - dev-libs/icu - dev-libs/json-c - dev-libs/libcroco - dev-libs/libffi - dev-libs/libgcrypt:0/20 - dev-libs/libtasn1:0/6 - dev-libs/nettle:0/6 - gnome-base/gconf - gnome-base/libgnome-keyring - media-gfx/graphite2 media-libs/alsa-lib - media-libs/harfbuzz:0/0.9.18 - media-libs/libart_lgpl - media-libs/libpng:0 - media-libs/libvorbis - media-libs/mesa - net-dns/libidn - net-libs/gnutls net-print/cups - sys-apps/tcp-wrappers - sys-apps/util-linux - x11-libs/libICE - x11-libs/libSM x11-libs/libX11 + x11-libs/libXcursor x11-libs/libXext x11-libs/libXi + x11-libs/libXinerama x11-libs/libXtst - x11-libs/libXxf86vm - x11-libs/libdrm - x11-libs/libxcb - x11-libs/libxshmfence x11-libs/startup-notification - x11-libs/xcb-util x11-themes/hicolor-icon-theme bundled-libs? ( - media-libs/jbigkit:0/2.1 media-libs/tiff:3 + x11-libs/libICE + x11-libs/libSM virtual/jpeg:62 ) !bundled-libs? ( ${BUNDLED_LIB_DEPENDS} ) @@ -223,35 +186,62 @@ } clean_bundled_libs() { - einfo "Removing bundled libraries" - for libname in ${BUNDLED_LIBS} ; do - rm -rv "${S}"/lib/lib/${libname} || die "Failed removing bundled ${libname}" - done - - rm -rv "${S}"/lib/libconf || die "Failed removing bundled gtk conf libs" - - # Among the bundled libs there are libcrypto.so.1.0.1 and libssl.so.1.0.1 - # (needed by libcds.so) which seem to be compiled from openssl-1.0.1h. - # Upstream real sonames are *so.1.0.0 so it's necessary to fix DT_NEEDED link - # in libcds.so to be able to use system libs. - pushd >/dev/null . - einfo "Patching libcds.so" - cd "${S}"/lib/lib/libcds.so || die - patchelf --replace-needed libssl.so.1.0.{1,0} \ - --replace-needed libcrypto.so.1.0.{1,0} \ - libcds.so || die - popd >/dev/null - - # vmware-workstation seems to use a custom version of libgksu2.so, for this reason - # we leave the bundled version. The libvmware-gksu.so library declares simply DT_NEEDED - # libgksu2.so.0 but it uses at runtime the bundled version, patch the lib to avoid portage - # preserve-libs mechanism to be triggered when a system lib is available (but not required) - pushd >/dev/null . - einfo "Patching libvmware-gksu.so" - cd "${S}"/lib/lib/libvmware-gksu.so || die - patchelf --set-rpath "\$ORIGIN/../libgksu2.so.0" \ - libvmware-gksu.so || die - popd >/dev/null + if ! use bundled-libs ; then + einfo "Removing bundled libraries" + for libname in ${BUNDLED_LIBS} ; do + rm -rv "${S}"/lib/lib/${libname} || die "Failed removing bundled ${libname}" + done + + rm -rv "${S}"/lib/libconf || die "Failed removing bundled gtk conf libs" + + # Among the bundled libs there are libcrypto.so.1.0.1 and libssl.so.1.0.1 + # (needed by libcds.so) which seem to be compiled from openssl-1.0.1h. + # Upstream real sonames are *so.1.0.0 so it's necessary to fix DT_NEEDED link + # in libcds.so to be able to use system libs. + pushd >/dev/null . + einfo "Patching libcds.so" + cd "${S}"/lib/lib/libcds.so || die + patchelf --replace-needed libssl.so.1.0.{1,0} \ + --replace-needed libcrypto.so.1.0.{1,0} \ + libcds.so || die + popd >/dev/null + + # vmware-workstation seems to use a custom version of libgksu2.so, for this reason + # we leave the bundled version. The libvmware-gksu.so library declares simply DT_NEEDED + # libgksu2.so.0 but it uses at runtime the bundled version, patch the lib to avoid portage + # preserve-libs mechanism to be triggered when a system lib is available (but not required) + pushd >/dev/null . + einfo "Patching libvmware-gksu.so" + cd "${S}"/lib/lib/libvmware-gksu.so || die + patchelf --set-rpath "\$ORIGIN/../libgksu2.so.0" \ + libvmware-gksu.so || die + popd >/dev/null + else + # if librsvg is not installed in the system then vmware doesn't start + pushd >/dev/null . + einfo "Patching svg_loader.so" + cd "${S}"/lib/libconf/lib/gtk-2.0/2.10.0/loaders || die + patchelf --set-rpath "\$ORIGIN/../../../../../lib/librsvg-2.so.2" \ + svg_loader.so || die + popd >/dev/null + + # vmware, even with VMWARE_USE_SHIPPED_LIBS set, uses the system lib + # for glib and fontconfig when a newer version is found. Let's force to use + # always the bundled versions to avoid a mix of system and bundled libs ... + pushd >/dev/null . + einfo "Patching appLoader" + cd "${S}"/lib/bin || die + patchelf --set-rpath "\$ORIGIN/../lib/libglib-2.0.so.0:\$ORIGIN/../lib/libfontconfig.so.1" \ + appLoader || die + popd >/dev/null + # ... this depends on previous appLoader patching, probably it is not mandatory but cleans the log + pushd >/dev/null . + einfo "Patching libfontconfig.so.1" + cd "${S}"/lib/lib/libfontconfig.so.1 || die + patchelf --set-rpath "\$ORIGIN/../libexpat.so.0" \ + libfontconfig.so.1 || die + popd >/dev/null + fi } src_prepare() { @@ -264,9 +254,7 @@ rm -f vmware-workstation-server/bin/{openssl,configure-hostd.sh} fi - if ! use bundled-libs ; then - clean_bundled_libs - fi + clean_bundled_libs DOC_CONTENTS=" /etc/env.d is updated during ${PN} installation. Please run:\n
try toggling the state of bundled-libs USE flag.
apploader is segfaulting in the vmware-overlay version. BTW, I am running gnome-3.20
Are you using an ~amd64 system? I guess you are using +bundled-libs useflag, is this correct? Is it crashing at startup or when running a vm? Please clean /tmp/vmware-[username]/*log, start vmware and attach the log files created in that folder.
right on startup. I am using bundled-libs.
Created attachment 430256 [details] vmware-apploader.log You can see it is not finding all the libs it needs.
I can see in the log VMWARE_USE_SHIPPED_LIBS is not set. With +bundled-libs the above envvar should be set in /etc/env.d/90vmware and it should be sourced in the session where vmware is launched from. Please be sure to source /etc/profile, verify that $VMWARE_USE_SHIPPED_LIBS is set, and then try again. Are you on a ~amd64 or amd64 system?
note: I am starting vmware-workstation this way: sudo systemd-run --scope --unit=vmware --slice=machine --uid=1000 vmware when I just run vmware from the terminal the apploader.log looks good but the vmware-ui.log shows a failure and it still does not start.
I am on ~amd64 and running gnome-3.20 from gnome-overlay
when run in a scope none of the variables are set but they are in the old ebuild in portage. If you are on systemd try starting in a scope and you should see the problem. It still does not start with the variables set on the new ebuild but it fails a little further on.
I'm not using systemd but basically the service is needed only when starting a vm, it's likely a problem not having defined VMWARE_USE_SHIPPED_LIBS in the service. Anyway the GUI can be run without having the service running. First step, let's have the GUI running, later will have a look at the service. Please clean again /tmp/vmware-[username]/*log and post *ALL* the new logs with VMWARE_USE_SHIPPED_LIBS set. Run from a shell. With bundled libs it should use only the libs embedded in the package.
with GUI I meant running vmplayer or vmware binaries from command line
Created attachment 430260 [details] apploader.log when running vmware from terminal
Created attachment 430262 [details] ui.log
this file is also there prw------- 1 harrisl users 0 Apr 12 17:29 vmware-:1-sp
Created attachment 430306 [details] change_rpath.sh Aggressive script used to set RPATH for all ELF objects shipped with vmware-workstation. When executing it's normal to get "stat: No such file or directory" warnings and a "maximum file size exceeded" error.
Comparing your ui log with mine it seems something related to Gtk theme. Right now I'm building a gnome desktop system to see if I'm able to replicate the problem. In the meantime please try the attached script change_rpath.sh on the vmware-workstation installation to see if there are any changes.
no difference in failed startup or logs after running change_rpath
Created attachment 430434 [details] vmware-workstation.ebuild Would you mind trying the attached ebuild? I have removed the part which enforces the use of embedded glib and fontconfig even if the system libs are more recent
More testing. The new ebuild didn't change anything. I also tried with -bundled-libs but that fails in the apploader. I went back to the ::gentoo ebuild and that is giving the same failure when launching as vmware from console. I am running successfully only when starting from a new scope using systemd-run. I am going the post the log for the successful run.
Created attachment 430530 [details] applog from systemd-run start on ::gentoo ebuild
Created attachment 430532 [details] ui.log from successful start using ::gentoo ebuild and systemd-run
(In reply to Harris Landgarten from comment #19) > More testing. The new ebuild didn't change anything. I also tried with > -bundled-libs but that fails in the apploader. I went back to the ::gentoo > ebuild and that is giving the same failure when launching as vmware from > console. > > I am running successfully only when starting from a new scope using > systemd-run. > > I am going the post the log for the successful run. I don't have systemd installed. Which is the exact command line are you using with systemd-run? From the log I can see that systemd ignores the VMWARE_USE_SHIPPED_LIBS envvar and /opt/vmware/lib/vmware/bin/thnuclnt command is called. Then a mix of bundled and system libs is used, definitely fontconfig and glib are coming from the system. But this behaviour should be the same when using vmware command from the ::gentoo ebuild with VMWARE_USE_SHIPPED_LIBS unset. Does it work with the two following alternative execution ways? $ VMWARE_USE_SHIPPED_LIBS=0 vmware $ unset VMWARE_USE_SHIPPED_LIBS $ vmware On a stable system (at least on mine without gnome installed) vmware starts w/ and w/o VMWARE_USE_SHIPPED_LIBS. From your experience and from bug #578070 (probably a duplicate of this) it seems that on your ~amd64 system VMWARE_USE_SHIPPED_LIBS must be not set at all. But I built an ~amd64 system without gnome and it did worked with VMWARE_USE_SHIPPED_LIBS set... This weekend I should be able to test with gnome installed on ~amd64.
unset VMWARE_USE_SHIPPED_LIBS vmware starts VMWARE_USE_SHIPPED_LIBS=0 vmware fails sudo systemd-run --scope --unit=vmware --slice=machine --uid=1000 vmware is what I am using. It could be written as a service unit file. systemd-run is a quick way to run a service
(In reply to Harris Landgarten from comment #23) > unset VMWARE_USE_SHIPPED_LIBS > vmware > > starts Do that procedure work also for ::vmware? If not, what about the ebuild attached to this bug report?
It does not work with ::vmware. I did not try it with the other ebuild yet.
I just tries the ebuild you posted in this bug with: unset VMWARE_USE_SHIPPED_LIBS vmware and it stared successfully
sorry, I was not able to reproduce completely your problem:-( I have created a clean ~amd64 virtual machine with default/linux/amd64/13.0/desktop/gnome/systemd profile and installed gnome 3.18.0. On this system I can run vmware from command line both from ::vmware overlay and also from the ebuild here attached with VMWARE_USE_SHIPPED_LIBS set. Moreover I can also run vmware as systemd scope unit as you suggested. amd64 and ~amd64 system from ::vmware and +bundled-libs: * VMWARE_USE_SHIPPED_LIBS set: - from command line works - with systemd-run works * VMWARE_USE_SHIPPED_LIBS not set: - from command line doesn't work - with systemd-run doesn't work amd64 and ~amd64 system from attached ebuild and +bundled-libs: * VMWARE_USE_SHIPPED_LIBS set: - from command line works - with systemd-run works * VMWARE_USE_SHIPPED_LIBS not set: - from command line works - with systemd-run works For the tests I have basically installed the two versions of vmware-workstation, checked that no vmware related process was still in background ("ps aux| grep vmware" is enough to identify one) and launch vmware/vmplayer from command line or using systemd as you suggested. No vmware services were running, I have tested only the GUI. Now I have changed the overlay removing the too aggressive patching of rpath. From the above tests it seems that the attached ebuild works independently from the value of VMWARE_USE_SHIPPED_LIBS. I don't understand why in your case it works only when unset. But it would be great to be able to understand the reason to see if it's necessary to remove the VMWARE_USE_SHIPPED_LIBS envar. This is the open issue before closing this bug.
I am running gnome 3.20 which could be the difference. You can do the same via the gnome overlay.
(In reply to Harris Landgarten from comment #28) > I am running gnome 3.20 which could be the difference. You can do the same > via the gnome overlay. I don't see any gnome-base/gnome-3.20.0 in the gnome overlay
If you install gnome overlay and update world you should get gnome 3.20
(In reply to Harris Landgarten from comment #30) > If you install gnome overlay and update world you should get gnome 3.20 nope, I have already installed the gnome overlay with layman, no specific gnome-base/gnome-3.20 there but I can see other 3.20.0 gnome-related packages (e.g. gnome-shell-3.20.1::gnome). Don't ask me what they are doing in the gnome overlay but I have latest ~amd64 installation done with gnome overlay installed.
Not sure if it will solve this problem, but there has been an updated version of vmware workstation out for about a month now. Version: 12.1.1-3770994
(In reply to Kenton Groombridge from comment #32) > Not sure if it will solve this problem, but there has been an updated > version of vmware workstation out for about a month now. Version: > 12.1.1-3770994 Pushed latest version, do you have the same problem?
With VMWARE_USE_SHIPPED_LIBS=1 and USE="bundled-libs", vmware still exits with "Loop on signal 11". With USE="-bundled-libs", it just immediately exits, so it doesn't look like 12.1.1 fixed the issue...
(In reply to Mike Auty from comment #34) > With VMWARE_USE_SHIPPED_LIBS=1 and USE="bundled-libs", vmware still exits > with "Loop on signal 11". With USE="-bundled-libs", it just immediately > exits, so it doesn't look like 12.1.1 fixed the issue... USE="-bundled-libs" is not supported with gcc 5.x. Besides that I cannot reproduce your problem as written above (I have also built a full ~amd64 system with gnome from scratch) :-( but it seems that unsetting VMWARE_USE_SHIPPED_LIBS helps. Can you try? $ unset VMWARE_USE_SHIPPED_LIBS $ vmware
I'm aware of that, you asked for people to test with 12.1.1 which is what I did. 5:) The upshot is, it made no difference. Unsetting VMWARE_USE_SHIPPED_LIBS still works fine.
This bug concerns unstable: . . . ACCEPT_KEYWORDS="amd64 ~amd64" REFERENCE: Bug 616958 : app-emulation/vmware-workstation-12.5.7 version bump [for "stable", excluding "~amd64"] Hi, Harris, to me, this bug seems to be OBSOLETE. Would you mind having this one closed and - in case - a fresh one opened against app-emulation/vmware-workstation-12.5.7 version bump ["~amd64"] in order to keep the issues involved separated? Kind regards Manfred I proposed the same to Billy: [ https://bugs.gentoo.org/show_bug.cgi?id=578070#c30 ]
VMware Products have been removed from Main Portage Tree during Nov-2017. Further development has been relegated to [vmware] Overlay. Situation as of today, 30-Nov-2017: Workstation : stable in [vmware] = 12.5.8 / released = 14.0.0 : Bug 634770 Player : stable in [vmware] = 12.5.8 / released = 14.0.0 : Bug 639162 Modules : stable in [vmware] = 308.5.8 / released = 329.0.0 : Bug 634862 Tools : stable in [vmware] = 10.1.6 / released = 10.1.15 : Bug 634854