Binary downloads? #1517

badvision · 2022-10-05T15:29:39Z

badvision
Oct 5, 2022

The link to the distribution packages seems to only go to Arch linux builds. I can't find other OS builds (windows, macOS would be wonderful, pretty please?) Also the download links in the wiki go to 2.3.3 version of the previous project this was forked from, not the current 2.4.0 release build. Also, when creating this bug I see the language "What version of barrier are you running" and I'm pretty sure that should be changed (but is a separate issue.)

Recommendation: Create releases in github for tagged version and include binary links to the releases. There's probably not a lot of benefit in maintaining separate wiki pages and download links elsewhere when you could just link to the most recent release in Github statically and be done.

Thanks and good luck with the fork!

mitchcapper · 2022-10-28T07:19:31Z

mitchcapper
Oct 28, 2022

They are adding CI binary artifacts so if you are logged in on the Actions tab you can grab daily's there.

16 replies

coquizen Mar 15, 2023

@vancluever Did you manage to somehow get it to register permissions to the Accessibility API?

vancluever Mar 15, 2023

@coquizen it did prompt for it and I added it, are you having issues?

vancluever Mar 15, 2023

@coquizen just confirmed that it's all working connecting back as a client to a barrier server. So yeah, looks like accessibility controls still work.

vancluever Mar 16, 2023

@coquizen one thing you might want to try - it looks like you can get stale entries in your privacy database if you end up doing a lot of installing/uninstalling of tools it looks like... maybe give this a shot:

tccutil reset Accessibility input-leap

You can also just do tccutil reset Accessibility but that will wipe all apps that have accessibility permissions and you will need to re-approve everything you use that needs access again.

Andrew-J-Larson Mar 21, 2023

@coquizen one thing you might want to try - it looks like you can get stale entries in your privacy database if you end up doing a lot of installing/uninstalling of tools it looks like... maybe give this a shot:
tccutil reset Accessibility input-leap
You can also just do tccutil reset Accessibility but that will wipe all apps that have accessibility permissions and you will need to re-approve everything you use that needs access again.

Thank you for this! This got barrier working again for me on my (Intel) Macbook running Ventura

rubycoder · 2022-11-27T20:04:49Z

rubycoder
Nov 27, 2022

Using the above artifacts on Windows, running barrier fails because vcruntime140_1d.dll isn't on my system. After some searching it seems that the preferred way of getting this dll is by installing the free Visual Studio Community edition (which then takes up many gigs of disk space).

Would it be possible to provide this dll with the artifacts? Or change the artifacts from a debug build to release, which should then use vcruntime140_1.dll which seems to be present on most Windows systems?

Or if you want to stay with a debug build, in my searching I came across this page
https://developercommunity.visualstudio.com/t/vcruntime140-1ddll-is-missing/888909
which has a comment near the bottom which talks about building "with debug /Zi but use /MD not /MDd so that your debug code has non debug c runtime dll's"

Thanks,

Wayne

2 replies

shymega Nov 27, 2022
Maintainer

The whole point of the CI builds for each commit is that, by design, they are only Debug builds. We could do Release builds for each commit, but that would extend the time of CI executions. I think until we start making more regular releases, you'll have to use the Debug builds with the runtime DLL as it requires, as they're ideally for developers.

However, I recognise the need for end-users to test patches, so I'll look into modifying the command-line switches, make a PR, and we can look into it with Povilas (@p12tic).

shymega Nov 27, 2022
Maintainer

We also use CMake for builds, so looking at the BATCH script, theres no way to pass that flag onto it. But I'm looking into it. Do you happen to know if using non-debug C++ runtime DLLs would make debugging more difficult? That's a balance I'm keeping in mind here.

rubycoder · 2022-11-27T20:41:43Z

rubycoder
Nov 27, 2022

if using non-debug C++ runtime DLLs would make debugging more difficult?

Sorry, but I don't know for sure. I programmed C++ on Windows for 15 years, but that's been 10++ years ago. But I don't guess it would cause any more than minor difficulties. Your code will have symbols, so you should be able to see and inspect any values that you pass into the runtime. I'm assuming that the runtime is pretty darn solid by now, so you should be able to count on it doing the right thing.

You should be able to debug your code, you just wouldn't be able to debug the runtime.

I wonder if there's some hack that would let you build using the non-debug runtime DLLs, but if you have a problem where you need to see into the runtime, you could use the debug runtime DLLs? The executable code is going to have the name of the DLL in plaintext (IIRC), so use a hex editor to edit the name to be the name of the debug runtime DLL??? (I realize the debug name is one character longer, so you might not be able to edit in place. If this is a problem, change the name in the executable and the name on the debug DLL file to something that's the same length as the non-debug name.)

Or, even simpler, on your system, "hide" the non-debug runtime DLL, then rename the debug runtime DLL to have the name of the non-debug DLL, so it loads that one. (Or maybe just copy it, so you would have 2 copies of the debug runtime DLL, one with its real name and one with the non-debug name?)

These hacks sound way too weird, so they would probably just blow up, but it should be fairly easy to run a test. And the hacks only exist in debug, release is still clean.

3 replies

shymega Nov 27, 2022
Maintainer

As long as the IL executables have debug symbols on Debug releases, and we can still inspect the IL processes, this is fine. It's not the runtime that needs to be debugged, it's the IL executables.

shymega Nov 27, 2022
Maintainer

@rubycoder Can you please try this build? https://github.com/shymega/input-leap/suites/9527773421/artifacts/452682592

ftoledo Dec 14, 2023

hi.. i get a "Failed to generate URL to download artifact. " error .

rubycoder · 2022-11-28T01:42:25Z

rubycoder
Nov 28, 2022

Sorry it took a while to respond.

I ran your build on a Windows 7 system (server) and a Windows 10 system (client)

On the Windows 7 system, the information in the Barrier window looks correct.
On the Windows 10 system, the bold IP address in the Barrier window appears to be incorrect. It is 192.168.240.2, which is the address of "Ethernet adapter VirtualBox Host-Only Network #8". Instead, it should have been 192.168.1.249, which is the address of "Wireless LAN adapter Wireless Network Connection".

I am unable to move the mouse cursor from the server screen to the client screen, probably because the client is trying to communicate on 192.168.240.2

Is there a way I can manually set the bold IP address on the client? I saw some references to things like this in the documentation, but I couldn't quite figure out how to do this.

Note that VirtualBox is installed (but not in use) on both systems, but doesn't seem to cause a problem on Windows 7.

4 replies

shymega Nov 28, 2022
Maintainer

OK, all I needed to test what that the new compile flags work. Seeing as Barrier launches, I can see the fix worked, and I'll make a PR.

It looks like the server is what the bold text is on, and it's listening on all adapters. I think you might be able to bind to an address, but my recommendation is that you open a new discussion to get help with that.

shymega Dec 1, 2022
Maintainer

@rubycoder You'll be glad to hear that my fix has made it into mainline, so future Windows builds shouldn't have this error. Thank you for pointing it out to me - and suggesting the fix 👍

rubycoder Dec 1, 2022

@shymega Thanks for letting me know! Glad I could help.

shymega Dec 2, 2022
Maintainer

@rubycoder No worries. Thanks again.

the-spyke · 2022-12-04T15:37:04Z

the-spyke
Dec 4, 2022

Please make a snap package available in Snap Store with edge channel tracking master branch.

4 replies

shymega Dec 4, 2022
Maintainer

I don't intend to make Snap or Flatpak or Scoop packages myself, as it adds to the maintainership tasks.

the-spyke Dec 4, 2022

The whole point of Snap and Flatpak is to lower maintainer burden, because you build the package once and it just works in 30 various distros. Anyway, thanks for answering.

shymega Dec 4, 2022
Maintainer

Oh, sorry - got confused. No, I was thinking of distribution-specific packaging. I can look into Snap. I have a Flatpak branch, but Scoop.. I'm not too sure.

the-spyke Dec 4, 2022

I'm fine with either Flatpak or Snap. Just wrote about the later because Barrier is currently installed from Snap. But I can switch. Don't know about Scoop as I don't use Windows.

Andrew-J-Larson · 2023-02-18T19:05:22Z

Andrew-J-Larson
Feb 18, 2023

Is there yet a working build for MacOS 13?

4 replies

shymega Feb 18, 2023
Maintainer

No. We're still working on modernising the codebase, and fixing bugs. There's no real need to ask - it'll come when it's ready:tm:

IMC-Dev Mar 6, 2023

Hey shy, tried building myself as well, albeit unsuccessfully.
Just want to say thank you for putting effort into this project and hope that it'll be available soon

shymega Mar 25, 2023
Maintainer

Hey shy, tried building myself as well, albeit unsuccessfully. Just want to say thank you for putting effort into this project and hope that it'll be available soon

@itaicas21 Thank you. I am getting a bit burnt out, but thank you for the kind words. It looks like a community member has got Input Leap on macOS working with a 'tap', I believe it's called, in this thread.

vancluever Mar 25, 2023

Indeed! It's a Homebrew tap - you can find it at https://github.com/vancluever/homebrew-input-leap. Enjoy!

vancluever · 2023-03-14T02:28:27Z

vancluever
Mar 14, 2023

Hey folks!!! I was able to build this on my M1 with Ventura!!! 🎉

It actually went surprisingly well, my only hiccup was that I hadn't installed the full XCode.app and also having to deal with code-signing issues (discussed below).

Building

Followed the steps here for the most part: https://github.com/input-leap/input-leap/wiki/Building-on-macOS

Note: I installed qt@5 directly but I guess qt5 is an alias for that 👍
Note: I also installed cmake from Homebrew but I'm not too sure if the full Xcode.app includes that (I only had command-line tools installed at first).

Note the caveats for qt@5 and openssl (brew info qt@5|openssl). This means you need to set your LDFLAGS, CPPFLAGS, and PKG_CONFIG_PATH appropriately:

export LDFLAGS="-L/opt/homebrew/opt/qt@5/lib -L/opt/homebrew/opt/openssl@3/lib"
export CPPFLAGS="-I/opt/homebrew/opt/qt@5/include -I/opt/homebrew/opt/openssl@3/include"
export PKG_CONFIG_PATH="/opt/homebrew/opt/qt@5/lib/pkgconfig:/opt/homebrew/opt/openssl@3/lib/pkgconfig"

I'm not too sure if this is 100% necessary, but I haven't tried building yet without doing this. I also just linked my Qt with brew link so I only populated the variables above with the OpenSSL stuff. I'm not 100% sure if this is necessary too but it looks like since MacOS defaults to LibreSSL I'd imagine it would be.

After installing the dependencies and setting the variables, running B_BUILD_TYPE=Release ./clean_build.sh built without any issues!

Signing

For things to work properly without a full-on crash (error will be Namespace CODESIGNING, Code 2 Invalid Page when you run the built InputLeap.app), you will need to self-sign the build:

codesign --deep --force --sign - build/bundle/InputLeap.app

After this, you should be able to run the app successfully! 🎉 If you have existing certificates and fingerprints (ie: from ~/Library/Application Support/Barrier), they should be copied over (they were for me).

Binary types

Also, dropping this here too, looks like everything built arm64 no problems?

$ file *
guiunittests: Mach-O 64-bit executable arm64
input-leap:   Mach-O 64-bit executable arm64
input-leapc:  Mach-O 64-bit executable arm64
input-leaps:  Mach-O 64-bit executable arm64

I also noticed that the guiunittests binary seems to be included in the .dmg even, guessing that might have to be removed during bundling, or skipped when B_BUILD_TYPE is Release.

Other Caveats

I haven't taken this for a full spin yet so I'm not too sure if it runs 100%. However, I figure that the fact that it builds, and the frontend runs, is a good sign. Also, running the executables directly (like input-leapc) seems to work.

If I run into anything else I'll update here!

11 replies

vancluever Mar 14, 2023

@shymega:

$ otool -L input-leap
input-leap:
	@loader_path/../Frameworks/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.15.0, current version 5.15.8)
	@loader_path/../Frameworks/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.15.0, current version 5.15.8)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 61.0.0)
	/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
	/System/Library/Frameworks/ScreenSaver.framework/Versions/A/ScreenSaver (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1953.255.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 169.0.0)
	@loader_path/../Frameworks/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.8)
	@loader_path/../Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.8)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)

$ file ../Frameworks/QtWidgets.framework/Versions/5/QtWidgets
../Frameworks/QtWidgets.framework/Versions/5/QtWidgets: Mach-O 64-bit dynamically linked shared library arm64

$ file ../Frameworks/QtNetwork.framework/Versions/5/QtNetwork
../Frameworks/QtNetwork.framework/Versions/5/QtNetwork: Mach-O 64-bit dynamically linked shared library arm64

$ file ../Frameworks/QtGui.framework/Versions/5/QtGui
../Frameworks/QtGui.framework/Versions/5/QtGui: Mach-O 64-bit dynamically linked shared library arm64

$ file ../Frameworks/QtCore.framework/Versions/5/QtCore
../Frameworks/QtCore.framework/Versions/5/QtCore: Mach-O 64-bit dynamically linked shared library arm64

I've also followed back a few of the references in each of the Qt dynlibs and it looks like their bundled dependencies are also arm64 (ie: libpcre, libglib, etc... anything that was bundled and is referenced relatively by @loader_path).

shymega Mar 14, 2023
Maintainer

We need to fix GH Actions CI as well as Azure, because there are some problems with the flows. I think the plan is to use a self-hosted runner on GH Actions.

I actually played around with the GH actions a bunch, fixing a bunch of things along the way, but ended up inlining all the build scripts to untangle what was happening. If it’s of interest, I can make a PR from that branch.

Ideally, we don't want to call cmake from CI. We want to use clean_build.sh/BAT, because there's a lot of OS-specific stuff there that 'just works'. Mostly. So whilst I appreciate your efforts, looking at your branch, it seems that there's a lot of direct cmake calls, meaning we'll have to keep track of multiple invocations of cmake.

shymega Mar 14, 2023
Maintainer

@shymega:

$ otool -L input-leap
input-leap:
	@loader_path/../Frameworks/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.15.0, current version 5.15.8)
	@loader_path/../Frameworks/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.15.0, current version 5.15.8)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 61.0.0)
	/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
	/System/Library/Frameworks/ScreenSaver.framework/Versions/A/ScreenSaver (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1953.255.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 169.0.0)
	@loader_path/../Frameworks/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.8)
	@loader_path/../Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.8)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)

$ file ../Frameworks/QtWidgets.framework/Versions/5/QtWidgets
../Frameworks/QtWidgets.framework/Versions/5/QtWidgets: Mach-O 64-bit dynamically linked shared library arm64

$ file ../Frameworks/QtNetwork.framework/Versions/5/QtNetwork
../Frameworks/QtNetwork.framework/Versions/5/QtNetwork: Mach-O 64-bit dynamically linked shared library arm64

$ file ../Frameworks/QtGui.framework/Versions/5/QtGui
../Frameworks/QtGui.framework/Versions/5/QtGui: Mach-O 64-bit dynamically linked shared library arm64

$ file ../Frameworks/QtCore.framework/Versions/5/QtCore
../Frameworks/QtCore.framework/Versions/5/QtCore: Mach-O 64-bit dynamically linked shared library arm64

I've also followed back a few of the references in each of the Qt dynlibs and it looks like their bundled dependencies are also arm64 (ie: libpcre, libglib, etc... anything that was bundled and is referenced relatively by @loader_path).

That's great, I wasn't aware Qt 5 could build on M1s. I know @p12tic has an M1 Mini, we discussed using an ARM64 VM on it as a GH Actions 'self-hosted runner', so we can definitely look into pursuing this. Maybe hop onto the IRC/Matrix channel?

vancluever Mar 15, 2023

@shymega I don't have an IRC client set up right now and I feel like timezones might be an issue anyway, hah. 🙂

Happy to help here with M1 testing or what not though... I'm definitely planning on wiring this up!

vancluever Mar 16, 2023

Just thought I'd leave breadcrumbs to #1623 here which has details on a Homebrew tap and formula I made to automate the install. 🙂

ftoledo · 2023-12-14T15:18:21Z

ftoledo
Dec 14, 2023

any change get a binary to run on windows 10 without install visual studio ?

0 replies

sithlord48 · 2024-02-24T15:20:57Z

sithlord48
Feb 24, 2024

Please See #1793 (comment)

0 replies

Binary downloads? #1517

Replies: 9 comments · 44 replies

shymega Nov 27, 2022 Maintainer

shymega Nov 27, 2022 Maintainer

shymega Nov 27, 2022 Maintainer

shymega Nov 27, 2022 Maintainer

shymega Nov 28, 2022 Maintainer

shymega Dec 1, 2022 Maintainer

shymega Dec 2, 2022 Maintainer

shymega Dec 4, 2022 Maintainer

shymega Dec 4, 2022 Maintainer

shymega Feb 18, 2023 Maintainer

shymega Mar 25, 2023 Maintainer

Building

Signing

Binary types

Other Caveats

shymega Mar 14, 2023 Maintainer

shymega Mar 14, 2023 Maintainer

Replies: 9 comments 44 replies

shymega Nov 27, 2022
Maintainer

shymega Nov 27, 2022
Maintainer

shymega Nov 27, 2022
Maintainer

shymega Nov 27, 2022
Maintainer

shymega Nov 28, 2022
Maintainer

shymega Dec 1, 2022
Maintainer

shymega Dec 2, 2022
Maintainer

shymega Dec 4, 2022
Maintainer

shymega Dec 4, 2022
Maintainer

shymega Feb 18, 2023
Maintainer

shymega Mar 25, 2023
Maintainer

shymega Mar 14, 2023
Maintainer

shymega Mar 14, 2023
Maintainer