mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 22:01:23 -06:00
[GH-ISSUE #234] Building on Ubuntu 18.04 resulted in "could not find or load the Qt platform plugin "xcb" in """ error message #192
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#192
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TafThorne on GitHub (Jan 21, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/234
Operating Systems
Server: Ubuntu 18.04
Client: Not involved yet
Barrier Version
v2.1.0
and current head of checked
4dedd88ab2Steps to reproduce bug
Checkout, build and installed the application as per: https://github.com/debauchee/barrier/wiki/Building-on-Linux
Attempt to run the applcation.
View
Other info
I have had other Qt applications installed and run.
I work as part of a team that does some Qt development, although I know nothing about it myself. This means I might have some odd config setup but AFAIK I removed all exisitng Qt development setup before I made this latest build and test attempt.
Full error outputs:
My appologies if this is a Qt issue rather than a Barrier one. I have tried to seach the internet for a solution but nothing I have found so far seems to have helped. I would welcome more suggestions for what I should try. I would be happy to perform more diagnostics if anyone can suggest some.
@AdrianKoshka commented on GitHub (Jan 21, 2019):
Any reason you're trying to build 2.1.0 rather than 2.1.1?
@TafThorne commented on GitHub (Jan 22, 2019):
I build 2.1.0 as it matched the version on my Windows client. I then build the latest to check that what I was seeing still happened. I can build 2.1.1 and 2.1.2 if you like.
v2.1.1 does the same.
v2.1.2 does the same.
As it is such a fundamental issue I am sure it must be something to do with Qt on my machine. However I have tried all the work arounds suggested so far, even removing all the Qt runtimes and development libraries I could and putting stuff back in. If my other Qt applications seem to work (kdiff3... although right now not git-cola)... Is there a place anyone can recommend I go to get help with making the magical runs anywhere framework to run?
@TafThorne commented on GitHub (Jan 22, 2019):
I have realised that this issue is very like one that developed with
git-colawhen I upgraded from Ubuntu 16.04 to Ubuntu 18.04. I raised a bug about it at the time: https://github.com/git-cola/git-cola/issues/869@AdrianKoshka commented on GitHub (Jan 22, 2019):
I'll try to build on 18.04 today. Just need to spin up a container I suppose.
@AdrianKoshka commented on GitHub (Jan 22, 2019):
Disregard that, I forgot your issue wasn't building, and was actually using it.
@AdrianKoshka commented on GitHub (Jan 22, 2019):
@AdrianKoshka commented on GitHub (Jan 22, 2019):
That was a build of 2.1.0
What I did:
output of
ldd:@AdrianKoshka commented on GitHub (Jan 22, 2019):
Sorry for not stating this earlier, but I've used the 2.1.2 release with the 2.1.0 windows executable and it works. That being said, I haven't done heavy testing, will probably get that chance soon.
@TafThorne commented on GitHub (Jan 25, 2019):
My Super User post has bourn fruit. I now have a workaround that gets barrier and my other problem applications working.
$ LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH barrierThis allows the application to run. There is either some confusion in my shared library paths (although other non-Qt and some Qt applications work) or the plugins path for Qt is incorrectly set. The latter may be hinted at by the message: "This application failed to start because it could not find or load the Qt platform plugin "xcb" in ""." with the in showing no path.
Answer that suggested the workaround is here: https://superuser.com/a/1397518/108734
If I find a persistent solution or the root cause I will return to post what it is. Unless there is something in the barrier package or install setup that should be setting a missing path, this is likely a fault in my Ubuntu and Qt configuration. Although I have applications such as Synergy which work in an older v1.8.8 version and fail in the newer v1.10.1 so there are ways an application could affect this.
@AdrianKoshka commented on GitHub (Jan 25, 2019):
I have a feeling that this is the case.
@AdrianKoshka commented on GitHub (Jan 25, 2019):
I could do some more random testing to see if I can replicate the issue, but I won't guarantee anything.
@TafThorne commented on GitHub (Jan 25, 2019):
I have checked my build of 2.1.0 against your build's ldd output.
If I then add my ldd output with the LD_LIBRARY_PATH set, I see a very good match with your own version:
The packages I am using in the problem case do not come from an Ubutnu package:
Do you have a
ls -la /lib/x86_64-linux-gnu/libQt5Core.so.5on your system? If not, it is possible this got added by mistake at some stage. Although the date on it being November 2017 would be the date I first installed this system. If you do have the file it will be an ordering config somewhere, I just need/usr/libto override/lib.@TafThorne commented on GitHub (Jan 25, 2019):
I think I finally found a likely source of my woes!
Looking at the order libraries are shared in mysetp gives
/lib/x86_64-linux-gnupriority over/usr/lib/x86_64-linux-gnufor me.I also have the handy warning I leave behind when setting myself landmines
# This file manually created by TafT after reading some internet advice. I am sure I do not need that file now as I no longer have that library set installed.Please, could you confirm if you have the
/etc/ld.so.conf.d/x86_64-linux-gnu.conffile and what its content is?I suspect that changing the order present in this file would remove my current problems, but it may cause new ones. If your working setup matches my broken one I will check elsewhere.
@AdrianKoshka commented on GitHub (Jan 25, 2019):
Sure, I still have that VM, let me boot it.
@AdrianKoshka commented on GitHub (Jan 25, 2019):
@TafThorne commented on GitHub (Jan 30, 2019):
Well your working machine matches my non-working one. Unless you get different output to
cat /etc/ld.so.conf.d/*than I did, I will need to start looking into the more specific Qt areas I guess.@AdrianKoshka commented on GitHub (Jan 31, 2019):
I think I'll close this issue then.