Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 562764 - [vmware] app-emulation/vmware-workstation-11.1.2.2780323-r3[-bundled-libs] fails with dev-libs/libgcrypt-1.5.4-r100:11/11
Summary: [vmware] app-emulation/vmware-workstation-11.1.2.2780323-r3[-bundled-libs] fa...
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo VMWare Bug Squashers [disabled]
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-10 21:13 UTC by Andreas K. Hüttel
Modified: 2015-10-23 05:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas K. Hüttel gentoo-dev 2015-10-10 21:13:26 UTC
Sven Eden 2015-10-09 14:39:20 CEST

When linked against dev-libs/libgcrypt-1.5.4-r100:11/11 vmware no longer starts but exits with exit code 255.
Comment 1 Andreas K. Hüttel gentoo-dev 2015-10-10 21:13:59 UTC
(In reply to Andreas K. Hüttel from comment #0)
> Sven Eden 2015-10-09 14:39:20 CEST
> 
> When linked against dev-libs/libgcrypt-1.5.4-r100:11/11 vmware no longer
> starts but exits with exit code 255.

Could you please add your emerge --info  ?!
Comment 2 Andreas K. Hüttel gentoo-dev 2015-10-10 23:30:03 UTC
This works fine for me here.
Comment 3 Manfred Knick 2015-10-11 11:18:09 UTC
In Gentoo Bug 538488 : https://bugs.gentoo.org/show_bug.cgi?id=538488 :

> As a note for the eventual _removal_ of 1.5.4,
> only two packages I can see need it.

vmware is not contained in the short list which follows,
so "Crypto team" are not aware of this need.

Placed a note for them in #13 :
   https://bugs.gentoo.org/show_bug.cgi?id=538488#c13
Comment 4 Manfred Knick 2015-10-11 12:45:19 UTC
> Sven Eden 2015-10-09 14:39:20 CEST
> 
> When linked against dev-libs/libgcrypt-1.5.4-r100:11/11 vmware no longer
> starts but exits with exit code 255.

Sven,

the following cleaning procedure helped me:

   https://bugs.gentoo.org/show_bug.cgi?id=562670#c4
Comment 5 Sven Eden 2015-10-12 08:29:06 UTC
Well, to add some information I forgot to add:

1) app-emulation/vmware-workstation-11.1.2.2780323-r1 works perfectly well with dev-libs/libgcrypt-1.5.4-r100 installed.

2) /etc/init.d/vmware starts and stops just nicely, no matter whether I use -r1 or -r3.

3) This wretched software is a nightmare to debug!

Okay, you knew about the latter, right?

Another problem with proprietary software. It silently fails with an odd exit code, but does nowhere tell you why. Horrible.

If r1 works and r3 doesn't, where should I start looking?

Of course there is the fact that the r1 ebuild uses the bundled libgcrypt in 
/opt/vmware/lib/vmware/lib/libgcrypt.so.11/libgcrypt.so.11

but I tried r3 with USE="bundled-libs" and it isn't working either. :(

However, I just saw that there is a new r4 ebuild, I'll try that.
Comment 6 Sven Eden 2015-10-12 09:41:43 UTC
There was no r4 ebuild. No idea what I've seen. Maybe a lack of coffee in the morning...

I think I found out what happened.

I have build my system using gcc-5.2.0. The only thing not correctly working with vmware is libglibmm, so I have to start vmware with:

LD_LIBRARY_PATH=/opt/vmware/lib/vmware/lib/libglibmm-2.4.so.1/:/usr/lib64/gtk-2.0/modules/:$LD_LIBRARY_PATH /opt/vmware/bin/vmware

Only that the new ebuild does not install libglibmm-2.4.so.1 any more and vmware does not like to use
  /usr/lib64/libglibmm-2.4.so.1
instead. It just doesn't work.

However, the issue is known to VMware, and this bug report is therefore invalid in the sense that libgcypt has nothing to do with it. 

However, there is no /opt/vmware/lib/vmware/lib/libglibmm-2.4.so.1 even if I emerge vmware-workstation with USE="bundled-libs" and that is a problem.

Should I open a new bug report for this?
Comment 7 Manfred Knick 2015-10-12 09:47:46 UTC
(In reply to Sven Eden from comment #5)

> 2) /etc/init.d/vmware starts and stops just nicely, no matter whether I use
> -r1 or -r3.

You do _not_ have those error messages in your
/var/log/vmware/vmware-usbarb-*.log 
as described in
https://bugs.gentoo.org/show_bug.cgi?id=562670#c4 ?
 
> 3) This wretched software is a nightmare to debug!
YES!
> Okay, you knew about the latter, right?
YES!

> ... It silently fails with an odd
> exit code, but does nowhere tell you why. Horrible.

> If r1 works and r3 doesn't, where should I start looking?

After init.t start:
. . . Nothing in /var/log/vmware/vmware ?

After vmware (application start):
. . . Nothing in /tmp/vmware-* ?

Perhaps you might be interested in reading Bug 562836 .

> ... there is a new r4 ebuild ...

Where?  (Not in layman -> vmware overlay - I've sync'ed that right now.)

I feel a bit lost about different concurrent (private) repositories ...

  @ Andreas:  Where is "the" "right" place too look at ?
Comment 8 Sven Eden 2015-10-12 10:16:24 UTC
(In reply to Manfred Knick from comment #7)
> After init.t start:
> . . . Nothing in /var/log/vmware/vmware ?
> 
> After vmware (application start):
> . . . Nothing in /tmp/vmware-* ?

I'll take a look.

> > ... there is a new r4 ebuild ...
> 
> Where?  (Not in layman -> vmware overlay - I've sync'ed that right now.)

As I wrote later, no. No idea what I've seen. Glitch of my eyes.

Okay, I made a file list after installing the -r1 ebuild, which works fine and a file list after installing the -r3 ebuild, with USE="bundled-libs".

The latter does not work and the following libraries are missing:

--------
 ~ # diff -u files_r1.lst files_r3.lst | grep -P "^-"
--- files_r1.lst        2015-10-12 12:00:24.984301219 +0200
-/opt/vmware/lib/vmware/lib/libatkmm-1.6.so.1/libatkmm-1.6.so.1
-/opt/vmware/lib/vmware/lib/libXcursor.so.1/libXcursor.so.1
-/opt/vmware/lib/vmware/lib/libXrandr.so.2/libXrandr.so.2
-/opt/vmware/lib/vmware/lib/libfreetype.so.6/libfreetype.so.6
-/opt/vmware/lib/vmware/lib/libgdk_pixbuf-2.0.so.0/libgdk_pixbuf-2.0.so.0
-/opt/vmware/lib/vmware/lib/libdbus-1.so.3/libdbus-1.so.3
-/opt/vmware/lib/vmware/lib/libXrender.so.1/libXrender.so.1
-/opt/vmware/lib/vmware/lib/libcurl.so.4/libcurl.so.4
-/opt/vmware/lib/vmware/lib/libaio.so.1/libaio.so.1
-/opt/vmware/lib/vmware/lib/libcairo.so.2/libcairo.so.2
-/opt/vmware/lib/vmware/lib/libgcrypt.so.11/libgcrypt.so.11
-/opt/vmware/lib/vmware/lib/libXdmcp.so.6/libXdmcp.so.6
-/opt/vmware/lib/vmware/lib/libcairomm-1.0.so.1/libcairomm-1.0.so.1
-/opt/vmware/lib/vmware/lib/libgailutil.so.18/libgailutil.so.18
-/opt/vmware/lib/vmware/lib/libXau.so.6/libXau.so.6
-/opt/vmware/lib/vmware/lib/libgiomm-2.4.so.1/libgiomm-2.4.so.1
-/opt/vmware/lib/vmware/lib/libXft.so.2/libXft.so.2
-/opt/vmware/lib/vmware/lib/libgio-2.0.so.0/libgio-2.0.so.0
-/opt/vmware/lib/vmware/lib/libatk-1.0.so.0/libatk-1.0.so.0
-/opt/vmware/lib/vmware/lib/libfuse.so.2/libfuse.so.2
-/opt/vmware/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0
-/opt/vmware/lib/vmware/lib/libXfixes.so.3/libXfixes.so.3
-/opt/vmware/lib/vmware/lib/libXcomposite.so.1/libXcomposite.so.1
-/opt/vmware/lib/vmware/lib/libfontconfig.so.1/libfontconfig.so.1
-/opt/vmware/lib/vmware/lib/libgdkmm-2.4.so.1/libgdkmm-2.4.so.1
-/opt/vmware/lib/vmware/lib/libatspi.so.0/libatspi.so.0
-/opt/vmware/lib/vmware/lib/libXinerama.so.1/libXinerama.so.1
-/opt/vmware/lib/vmware/lib/libXdamage.so.1/libXdamage.so.1
--------

If I tell the ebuild I want bundled-libs, why are so many removed nevertheless? 

If I take a look in the ebuild, it lists the bundled libs in RDEPEND if the USE flag is not set.

But the libs get cleaned, no matter whether the USE flag is set or not. So actually all this USE flag does, is to pull in the required libraries as dependencies if unset, but removes them even if the flag is set. A bug I daresay.


So lets take a look into the log file.

Yes, it complains about the same files like in bug 562836 - Can this be the issue?

Let's downgrade and have another look...

Yes. With the -r1 ebuild, the log shows the very same errors about files it can't find and the missing socket, but vmware-workstation works fine.
Comment 9 Manfred Knick 2015-10-12 14:42:49 UTC
RDEPEND=" ...
 !bundled-libs? ( ${BUNDLED_LIB_DEPENDS} ) ..."

@ Sven :

I just checked that combining 
[ -r3 ] RDEPEND entries with those from BUNDLED_LIB_DEPENDS
results into a super-set of 
[ -r1 ] RDEPEND entries.

Could you please consider to provide your
"emerge --info vmware-workstation" output?

Esp.: Are you on gcc-4.9 still , or also on gcc-5.2 already ?

Mine you find @ Bug 562836 , attachment  "emerge --info vmware-workstation" ,
https://bugs.gentoo.org/attachment.cgi?id=414374 .
Comment 10 Andreas K. Hüttel gentoo-dev 2015-10-12 22:48:27 UTC
(In reply to Sven Eden from comment #6)
> There was no r4 ebuild. No idea what I've seen. Maybe a lack of coffee in
> the morning...
> 
> I think I found out what happened.
> 
> I have build my system using gcc-5.2.0. The only thing not correctly working
> with vmware is libglibmm, so I have to start vmware with:

If you're using gcc-5, you will *have* to use USE=bundled-libs

And possibly some additional hacks are needed which I'm still working on (to make sure libs from /opt/vmware are preferred).

(c++ libraries compiled with gcc-5 are not binary-compatible.)
Comment 11 Manfred Knick 2015-10-13 08:56:36 UTC
(In reply to Andreas K. Hüttel from comment #10)

> If you're using gcc-5, you will *have* to use USE=bundled-libs
 
> (c++ libraries compiled with gcc-5 are not binary-compatible.)

*cross-reference* to 

. . . https://bugs.gentoo.org/show_bug.cgi?id=562836#c12
Comment 12 Sven Eden 2015-10-23 05:17:23 UTC
(In reply to Andreas K. Hüttel from comment #10)
> (In reply to Sven Eden from comment #6)
> > There was no r4 ebuild. No idea what I've seen. Maybe a lack of coffee in
> > the morning...
> > 
> > I think I found out what happened.
> > 
> > I have build my system using gcc-5.2.0. The only thing not correctly working
> > with vmware is libglibmm, so I have to start vmware with:
> 
> If you're using gcc-5, you will *have* to use USE=bundled-libs
> 
> And possibly some additional hacks are needed which I'm still working on (to
> make sure libs from /opt/vmware are preferred).
> 
> (c++ libraries compiled with gcc-5 are not binary-compatible.)

As I already said, the true bug is, that the bundled libraries got cleaned no matter whether USE="bundled-libs" was set or not. That got me confused, sorry.