Linux x64/Steam Games/Mumble Overlay doesn't work.

[grappas]

Why?

[mkrautz]

The way to accomplish this would be to run the Steam client via the mumble-overlay launcher.

That should, in theory, work. But I honestly don't know, because I haven't tested it in a long time.

Please report back!

Why do you need the mumble-overlay launcher in the first place? Because we can't auto-inject the overlay into other processes on Linux without violating people's expectations of what Mumble should do. :-)

So, you'll have to use the launcher for now.

[grappas]

~$mumble-overlay mumble-overlay steam steam://rungameid/570
set
/bin/bash: symbol lookup error: /usr/lib/mumble/libmumble.so.1: undefined symbol: glPopClientAttrib

 

using version: 1.3.0~646~g5a8c7f5~snapshot-1~ppa1~vivid1

same was for 1.2.8 stable version.

[mkrautz]

Looking into this for you...

Right now, we expect the injection target to use libGL, or have libGL symbols in it. That's not the case for the main Steam binary, so it fails.

Perhaps you're able to run Dota 2 from the command line via mumble-overlay. That should, in theory, work. (If the architecture between your libmumble.so and Dota 2 matches).

Anyway: I'm looking into a more suitable solution...

[mkrautz]

I've fixed a few Linux GL overlay things:

https://github.com/mumble-voip/mumble/commit/06e19e6fb191afa794f8018b67252940bc097fdd

https://github.com/mumble-voip/mumble/commit/859da4dabec070959b5c06f8d32512990d7ec9c2

and triggered a new snapshot... Should be out soon.

FWIW, I don't know if Dota 2 runs as an x86 or x86_64 application on Linux.

If your Mumble is x86_64, the overlay libs will only work with x86_64 programs, and vice versa.

So... Please try out the new snapshot ("1.3.0~657~g06e19e6~snapshot") and see if it makes it any better!

[grappas]

But mumble-overlay script is looking for all libs to put to an application.

 

for libpath in /usr/lib /usr/lib/mumble /usr/lib32 /usr/lib32/mumble /usr/lib64 /usr/lib64/mumble; do
 if [ -d "$libpath" ]; then
   if [ -f "$libpath/libmumble.so.1" ]; then
     case $(file -L "$libpath/libmumble.so.1") in
       *64-bit*) MUMBLE_OVERLAY_PATH_64="$libpath" ; echo set ;;
       *32-bit*) MUMBLE_OVERLAY_PATH_32="$libpath" ;;
     esac
   fi
 fi
done

 

but /usr/lib32/mumble is missing. Why don't u just put libs for both architectures? It's obvious nowadays that newest machines are running x64 operating systems (and are handling both x86 and x64 apps). Putting only x64 doesn't make sense because most of games are still x86.

EDIT:

 

If your Mumble is x86_64, the overlay libs will only work with x86_64 programs, and vice versa.

After upgrade:

mumble-overlay steam steam://rungameid/570set
/bin/sh: symbol lookup error: /usr/lib/mumble/libmumble.so.1: undefined symbol: glPopClientAttrib

Edited June 5, 2015 by grappas

[mkrautz]

The package is from before there was good multiarch support in dpkg.

It's not clear to me how you're supposed to accomplish this while still complying with distro guidelines.

If you have any idea, please contribute.

The easiest way to do it, AFAICS, would be to split the overlay shared library and have that be a separate package that Mumble can depend on.

That way you could simply install mumble-overlay:i386 and mumble-overlay:amd64, and be good.

[mkrautz]

If you're still getting...

 

mumble-overlay steam steam://rungameid/570set

/bin/sh: symbol lookup error: /usr/lib/mumble/libmumble.so.1: undefined symbol: glPopClientAttrib

 

...are you sure the Mumble package is really up-to-date?

[grappas]

Umm... mumble-overlay is intergrated with mumble package and is independant from arch because it's an universal script.

After installing mumble:i386:

 

mumble-overlay steam steam://rungameid/570ERROR: ld.so: object '/usr/lib/mumble/libmumble.so.1' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Running Steam on ubuntu 15.04 64-bit
STEAM_RUNTIME is enabled automatically

 

And mumble still works fine, unfortunately without mumble-overlay.

Edited June 5, 2015 by grappas

[mkrautz]

I've just emailed the Debian package maintainer to get his view the multiarch problem.

Once we have a solution that's acceptable to Debian, we can move it into our PPA packages, too.

[mkrautz]

Umm... mumble-overlay is intergrated with mumble package and is independant from arch because it's a universal script.

After installing mumble:i386:

 

mumble-overlay steam steam://rungameid/570ERROR: ld.so: object '/usr/lib/mumble/libmumble.so.1' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Running Steam on ubuntu 15.04 64-bit
STEAM_RUNTIME is enabled automatically

 

The script is arch independent, yeah. It's a shell script.

However, the overlay library is not. It lives in /usr/lib/mumble (not multiarch aware).

So if you install mumble:i386, you'll get the i386 version, and if you install mumble:amd64 you'll get the amd64 version...

So, it's not really ideal, at all. Sorry.

[grappas]

If you're still getting...

 

mumble-overlay steam steam://rungameid/570set

/bin/sh: symbol lookup error: /usr/lib/mumble/libmumble.so.1: undefined symbol: glPopClientAttrib

 

...are you sure the Mumble package is really up-to-date?

 

Yes.

[mkrautz]

Unable to reproduce that with mumble 1.3.0~657~g06e19e6~snapshot~1~ppa1~utopic1...

I don't think vivid should break that... Hm.

[mkrautz]

Build log also agrees that it's been built with '-z lazy': https://launchpadlibrarian.net/208359468/buildlog_ubuntu-vivid-i386.mumble_1.3.0~657~g06e19e6~snapshot-1~ppa1~vivid1_BUILDING.txt.gz

[grappas]

Umm... mumble-overlay is intergrated with mumble package and is independant from arch because it's a universal script.

After installing mumble:i386:

 

mumble-overlay steam steam://rungameid/570ERROR: ld.so: object '/usr/lib/mumble/libmumble.so.1' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Running Steam on ubuntu 15.04 64-bit
STEAM_RUNTIME is enabled automatically

 

The script is arch independent, yeah. It's a shell script.

However, the overlay library is not. It lives in /usr/lib/mumble (not multiarch aware).

So if you install mumble:i386, you'll get the i386 version, and if you install mumble:amd64 you'll get the amd64 version...

So, it's not really ideal, at all. Sorry.

 

Still it doesn't make change to me. Overlay is not working.

[mkrautz]

The best way for me to troubleshoot would be if you could find the Dota 2 binary on disk and determine if it's i386 or amd64.

Then, install Mumble for the arch that Dota 2 is using.

Then, you could try to launch it directly:

 

LD_PRELOAD=/usr/lib/mumble/libmumble.so.1.3.0 /path/to/dota2/binary

or simply

mumble-overlay /path/to/dota2/binary

(they're equivalent)

 

If you really do want to launch through Steam:

I am not sure launching through Steam works, but I believe it should. But note that it will only ever work if the initial Steam process has the LD_PRELOAD env var set up correctly. Then, if Steam correctly propagates the environment variables to its child processes, the assumption is that Dota 2 will launch with libmumble.so set in the LD_PRELOAD environment variable, and thus get the overlay.

But if I am to troubleshoot it for you, I would recommend you try to launch it directly as described above.

You can also set the MUMBLE_OVERLAY_DEBUG environment variable to 1 in order to get the overlay to print debug messages.

[grappas]

It's i386. I've even tried put LD_PRELOAD to dota 2 launch script. Without results (mumble:i386 of course)

Launching dota 2 directly from binary wont work because launch script loads other libs.

Edited June 5, 2015 by grappas

[mkrautz]

Anything useful printed?

Also, please try to

 

export MUMBLE_OVERLAY_DEBUG=1

 

before running Dota. That should hopefully print something.

Thanks.

[grappas]

I can't get to those logs because script loads the game and instantly and shuts down terminal.

[mkrautz]

OK. I wonder if it simply tries to run it via Steam URL or something.

Should be possible to launch the binary directory, I suppose... I don't have a Linux machine available to test on right now, though.

Anyway, this doesn't really work. I guess I'll have to try it myself later...

[grappas]

I've tried that too but there's tenths of envs that should be injected, so I gave up.