[SOLVED] undef symbol: gdk_wayland_display_get_wl_compositor

[mahdi1234]

Hi,

I'm using binary Tor browser form the site here https://www.torproject.org/download/ after update to latest version it won't start with

[fedeliallalinea]

You are not the only, but I've no idea how to fix
_________________
Questions are guaranteed in life; Answers aren't.

[alamahant]

Is it

[mahdi1234]

[alamahant]

[mahdi1234]

Yes there was Mesa and one more package in dep tree ... unfortunately I did not have older build anymore.
_________________
http://gentoo.mahdi.cz <-- gentoo package search engine

[qsmodo]

Thanks, I was also stuck on this since yesterday.

However, it's a painful workaround. I'm already suffering in advance for the hours of compilation this entails. I wish Tor Browser maintainers would instead withdraw that awkward dependency...

[ExecutorElassus]

As was noted on the torbrowser project's issue tracker, main Firefox seems to compile fine without wayland installed, so there's something torbrowser itself is doing weird that's breaking this.

For now, I guess compile mesa and gtk+ with wayland?

Cheers,

EE

[sam_]

Related: see bug 624960 - gtk's ABI changes based on whether it was built with Wayland support and it leaks into consumers. Difficult to solve properly (see bug 680496 for the solution we likely need).

[qsmodo]

This is just to echo the workaround provided by a user in the Gitlab's issue and adapt it to Gentoo's context.

shim.c:

[Hu]

That seems like a bad approach. How is your user able to rewrite the desktop file at all, and what is overwriting it afterward? Why are you using mv instead of sed -i?

[qsmodo]

I have enough permissions. What overwrites it afterward is Tor Browser itself, probably /opt/tor-browser_en-US/Browser/start-tor-browser.

I use mv instead of sed -i because the latter is not portable, and worse, some Sed implementations want an "argument" to -i and thus fail.

[Hu]

You shouldn't have enough permissions though. As a file in /opt, rewriting that ought to be restricted to root. What sed implementation requires an argument to -i? Are any of those implementations even used on Gentoo?

[qsmodo]

Not trying to be snarky here, but can you explain why I shouldn't have enough permissions?

I know Mac OS' sed requires an argument to -i. I can't tell whether any implementation with same behavior is used on Gentoo, so I reckon using -i for the sake of saving a simple extra mv line is a risk not worth taking when I'm posting this for anyone to read.

[Hu]

I explained it above. Files in /opt ought not be writable to non-root users. You are presumably using a non-root user. Therefore, you are presumably using a user who should not be able to rewrite that file. Are you using the root user to run your browser, or are the permissions on this file wrong?

Mac OS is well known for shipping BSD-derived tools, rather than GNU tools; in my experience, BSD tools frequently have weird misfeatures like the one you describe. From trying to read up on this, it looks like it is the case that even the BSD sed can be made to behave by explicitly providing an empty suffix. Unfortunately, that causes GNU sed to do the wrong thing:

[qsmodo]

I'm glad we are having a constructive conversation, Hu.

[Hu]

That premise is a specific case of the more general premise: directories not specifically allocated to users are directories for system-wide use, and unprivileged users should not be able to add, modify, or delete files in system-wide directories. This is why we don't allow unprivileged users to create files in /usr/bin, or under /usr/local. With limited exceptions, standard practice is that there are no directories which are writable by multiple users, and which allow users to modify each others' files. /tmp is world-writable, but the sticky bit protects against users replacing each others' files. Often, /tmp will also be mounted noexec, which further reduces a user's ability to disrupt other users. Every other exception I am aware of is reserved to specific applications that have their own locking rules, and generally store only files that can be lost without serious consequence (such as a High Scores table for a game).

On a typical install, /opt/bin is part of the $PATH for all users, including root. It would be a security problem if an unprivileged user could add executable programs that other users would find via $PATH, because then users other than the creator might unintentionally run such a file. It is the responsibility of the root user to prevent this problem by not creating any directories that are both writable to users and treated as "system-wide" by common conventions. (Arguably, a system where root has specifically arranged that /opt is not in the standard $PATH would then be safe to allow users to write to /opt. Personally, I would push users somewhere else, because even if /opt is not in $PATH, it is still a well-known name that, by convention, is only writable to root, so some users or programs might still assume the latter and do something unsafe, even if it isn't in $PATH.)

On my system, the LLVM bin directory is lower in $PATH than /opt/bin, so someone with write access to /opt/bin could create a file, such as /opt/bin/llvm-cxxfilt, that would be run in preference to the real LLVM's llvm-cxxfilt. Then, when next I run a bare llvm-cxxfilt < something, I run their version in /opt/bin instead of the version I expected to be found at /usr/lib/llvm/version/bin/llvm-cxxfilt. This will at the very least be surprising, if they exec the real one with different options. It could be a security problem if their program also uses its authority as me to compromise my account, by uploading gpg or ssh keys, by modifying my dotfiles to run something malicious later, etc.

Gentoo packages of prebuilt binaries, such as firefox-bin or rust-bin, typically install under /opt, so when I saw that you had Tor Browser there, my expectation was that you had used an overlay that installed the files there. Such an overlay should not have made them writable to your user. Based on your latest post, you didn't use an overlay; you used a root shell to mv those files there. If you had put them somewhere else, I would have more readily recognized that this was not a package manager controlled install. If you had changed their ownership to root when you moved them, then the browser wouldn't be rewriting its desktop file, your post would not have needed to warn about the rewrite, and I would've assumed the files were safe. Referring to /opt as "default installation path" also sounds to me like a scripted install picked that directory for you.

[qsmodo]

Oh, sorry for "default installation path", that was totally incorrect since I put the files there myself. I edited the post to remove that incorrect statement.

Thank you for expanding on the /opt part, that's much appreciated.

[psycho]

Qsmodo, thank you for this great little workaround (the custom shim.so).

[lyghters]

[flexibeast]

@Hu:

As a data point, i just tested sed(1) on one of my OpenBSD (7.4) servers; the '-i' option can be used without having to supply an argument.