mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #852] Provide a 32bit OR ARM build for Windows (Surface Pro X) #678
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#678
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 @martinkoutecky on GitHub (Aug 28, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/852
It is not possible to run the current (2.3.3) windows build on Surface Pro X, which is an ARM device with emulation for 32bit windows applications.
An ideal solution would be a native (ARM) build of barrier for windows. A perhaps easier and sufficient solution would be a 32bit windows build.
Seems related to #830 which asks for a 32bit linux build.
@shymega commented on GitHub (Aug 28, 2020):
Yes, 32-bit support should be added again. I'm looking into ARM builds, but we would have to see how easy that would be with Azure Pipelines. I'm sure it would be possible with cross-compiling. Could you confirm the exact model of your Surface Pro X? There's different types of ARM chips, for example -
armv6,armv6, hard/soft floating points, etc.@martinkoutecky commented on GitHub (Aug 29, 2020):
Hi - I'm not sure how to answer the question. I think there is only one CPU in the Surface Pro X, which is the Microsoft SQ1, which is basically Cortex-A76 / A55 (Kryo 495) (some more info here) -- when I look at downloads of other software, I'm looking for "aarch64". According to wiki it should be specifically ARMv8-A.
If there are any specific questions you have or diagnostics I could run I'd be happy to. Thanks for looking into it!
@shymega commented on GitHub (Sep 1, 2020):
Hi, thanks forgetting back to me.
I'm looking into it still, but I need to see how easy it would be. I think on Windows its achievable. I can't test it on CI right now though.
I have, however, been able to build the barrier, barriers and barrierc executables on my Windows machine. I have zipped them up and attached to this issue. Let me know if that works, as they should be x86 now.
There's no installer, as I haven't got that far, and I wanted to get something whipped up quick for you.
** Ignore this previous link! Built with Qt x64 by mistake. **
I'm gonna create a issue about Azure Pipelines having x86/aarch64 support in the future.
@shymega commented on GitHub (Sep 1, 2020):
Rebuilding from v2.3.3 and with x86 Qt. Made a mistake.
@shymega commented on GitHub (Sep 1, 2020):
Finished the build.
Barrier-v2.3.3-x86-executables.zip
With regards to aarch64 support: so Qt, OpenSSL, and Bonjour would be one of the issues here. I'm not sure how easy it would be to convince VS to compile to aarch64. I can do some more research, but for now I suspect you will have to just use 32-bit, sorry. If you, or any others, have ideas on how to accomplish CI builds on aarch64, I'd be open to suggestions 😄
@shymega commented on GitHub (Sep 1, 2020):
Oops, didn't mean to close that. I will wait for your response first..
@martinkoutecky commented on GitHub (Sep 1, 2020):
Hi @shymega -- thanks a lot for your effort! Now I'm getting "Qt5Network.dll not found". Previously I was missing ssleay32.ssl and libeay32.ssl, but I can see that's fixed. I tried installing Qt5 for windows but that hasn't helped. Is there a way to bundle those libs with it? Or what can I download and install to make it run?
@shymega commented on GitHub (Sep 1, 2020):
Uhhh.. I thought I had bundled Qt with it. You could probably install Qt 5, and it'd be fixed. Give that a try, and let me know if it works :)
@martinkoutecky commented on GitHub (Sep 1, 2020):
As I said - I've tried installing Qt5, which seemed quite complicated (needed to create a qt account, etc.), but it didn't work anyway? Sorry for this silly question, but how did you install Qt5? (definitely Qt5Network.dll is not in the folder you supplied.)
@shymega commented on GitHub (Sep 1, 2020):
Sorry, totally misread that. We use a Python script to download Qt 5, and then MSVC (on WIndows, anyway) links the Qt DLLs into Barrier. Same with Bonjour and OpenSSL. So what I've done, is used the 32-bit version of OpenSSL, Qt, and Bonjour right now.
But this is where the tricky part comes in for ARM64- the Bonjour 'stub' SDK we use only has support for Win32 and x64 right now. I need to open a issue and ask if we can get alternative architectures supported for Barrier. Then, we have OpenSSL. All of these must be compiled in ARM64 'format' for them to be linked to the Barrier executable.
All in all, we need to have a rethink about our builds. Personally, I see no reason to stop supporting 32-bit, and ARM64 would be - imho - a welcome addition in the future.
I'm just looking into getting the Qt DLLs into the folder, one moment.
@shymega commented on GitHub (Sep 1, 2020):
OK. I've attached the new ZIP here. That should work. In theory...
I've opened an issue on the script's repo, too.
Barrier-v2.3.3-x86-executables.zip
@martinkoutecky commented on GitHub (Sep 1, 2020):
Hi - thanks again. Now the message I'm getting is this, which I don't understand:
Again thanks so much for giving this the attention! As I said, I'm not much worried about having a native build, but getting this x32 thing running would be amazing for my workflow, so I really appreciate the help.
@martinkoutecky commented on GitHub (Sep 1, 2020):
BTW running the executables from terminal doesn't turn out any errors, it's just that it's hard for me to configure barrier without the GUI. But I might give it a try tomorrow (unless you have a new build for me) and see if I can get it running without the GUI after all.
@shymega commented on GitHub (Sep 1, 2020):
OK, so basically, I'm running this build step-by-step from
clean_build.bat, and there's a lot of things to factor in.Please try moving
qwindows.dllto theplatformsfolder, and try again.@shymega commented on GitHub (Sep 1, 2020):
Confirmed working on Windows 10, 2004.
@martinkoutecky commented on GitHub (Sep 2, 2020):
Hi - thanks again. Now I've got the GUI running, but the log keeps saying
"INFO: connecting to service..."and then"ERROR: ipc connection error, connection refused". I assume this is because the barrier service is not running, which may be because just copying files over is not a proper install? I.e., how do I run the service? When I try runningbarrierd.exe(either as a normal user or admin), it says"cannot connect to network hub"(or maybe it's socket - I'm getting the error message in Czech).Also, when I try to run from terminal
./barrierc.exe 192.168.0.144(my server IP), I get a timeout, and on the server I getThe client is Windows 10 ARM, the server is openSUSE linux with barrier 2.3.2.
I'm not sure this is still connected to the x32 issue, but it seems maybe there are two issues at play, one with barrierd perhaps not running on the client, and then maybe some SSL issue (as shown in the log of the server)?
@martinkoutecky commented on GitHub (Sep 2, 2020):
OK: I've got it running, sort of -- the main missing piece now is SSL. Steps to get it running.
./barrierc.exe 192.168.0.144Then it seems to work. With SSL enabled I'm getting the timeout on the client, and the same error message as above on the server.
@martinkoutecky commented on GitHub (Sep 2, 2020):
So some more progress: now I've got it running completely, even with SSL. I had to manually generate the server fingerprint and put it in TrustedServers.txt in the right location. I would definitely prefer to use the GUI for all this, but maybe that gets fixed when there's a proper install package for x32 which installs the service (barrierd), because I think the reason the GUI is not yet useful is the problem with connecting to barrierd. Just my guess.
Anyway, this is essentially satisfactory now for me - thanks a lot for your help. I would say this is closed once there is an x32 build in the Releases, but I'm leaving this up to you.
@foxtrotdragon commented on GitHub (Oct 21, 2020):
I would like to say, on my asus t100ta the linked build works pretty much flawlessly moving windows, and adding barrierd as a service in windows. I have been using it multiple days without issue (Aside from lag caused by shoddy network hardware)
@OKNoah commented on GitHub (Nov 21, 2020):
We'll need an Apple M-series build as well.
@shymega commented on GitHub (Nov 21, 2020):
As far as I know, Apple's M-series CPUs support x86_64 builds, so Barrier should still work. However, and this comment should explain things further, I would not be in a position to make any more builds. I did not even get round to adding CI support for ARM64 builds...
@mkostersitz commented on GitHub (Nov 23, 2020):
I am trying to get this working the other way round. Windows X as the server and Mac OS Big Sur as the clients.
Both sides seem stuck at Barrier is starting.
On the Mac Side I am seeing "failed to connect to server: server refused client with our name. .local"
Got it working. Had to drag a new screen into the config, name it and restart server and client. Now I am connected.
@shymega commented on GitHub (Nov 23, 2020):
@mkostersitz Good to hear, but your issue was unrelated to this. Please either ask on IRC, or open a new issue in future...
@willis936 commented on GitHub (Dec 14, 2020):
I'm having this issue on Windows 7 32-bit. I copied the executables from the artifact attached to this comment (https://github.com/debauchee/barrier/issues/852#issuecomment-685085964) but I now have the unsupported Qt platform error. qwindows.dll is in the installed platforms directory.
The platforms directory in the referenced artifact is empty. Could someone with a build environment upload a copy with the correct qwindows.dll?
@shymega commented on GitHub (Dec 14, 2020):
I did say in a later comment that you need to move the
qwindows.dllfile to theplatformssubdirectory. The artifact does not have the required directory structure due to a typo on my part. Try that.@willis936 commented on GitHub (Dec 14, 2020):
I copied/replaced the executables directory on top of an existing Barrier install that had
qwindows.dllin itsplatformssubdirectory. I have also tried copying theqwindows.dllto the extracted directory'splatformssubdirectory and launching barrier.exe from there. Both return the Qt platform plugin initialization error.Edit: Oh I see. The version of
qwindows.dllin the top directory needs to be present in theplatformssubdirectory. I hadn't realized the dll was present in the top level directory.@shymega commented on GitHub (Dec 15, 2020):
Does it work now? AFAIK, you can't really use it on top of a Barrier install - that'd be mixing things..... but if it works, that's good.
@willis936 commented on GitHub (Dec 15, 2020):
It is working now on Windows 7 32-bit with the copy on top of an install. I wanted windows to be aware of the shortcuts.