-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows on arm build #218
Comments
A valid feature request but don't expect me to work on it anytime soon. Note that this will most likely compile (and if not only trivial fixes should be necessary) so anybody is welcome to provide builds for that architecture similar to other additional builds that are already listed in the README's download section. If you want to use Syncthing Tray on Windows/ARM right now then it is likely best to use the x86_64 build of Syncthing Tray in combination with the ARM build of Syncthing itself. (So basically avoid using the built-in Syncthing library so at least Syncthing itself runs natively.) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Copying the file from msys2 works. |
I guess I'll have to dive into the CMake code again then… Good that you've tested with the DLL from MSYS2. This way we know that the DLL is the only problem and that the executable generally works. |
I built a new version: https://martchus.dyn.f3l.de/repo/arch/ownstuff-experimental/os/x86_64/mingw-w64-clang-aarch64-syncthingtray-qt6-1.6.3-1-any.pkg.tar.zst (This package has the version 1.6.3 but it is actually a development build.) This one should work (according to |
Works fine. The last version seemed exited after one night's sleep , I will see if this one also exit. |
Also exit after one night' s sleep. |
I suppose it "just" crashes. It is hard to tell why. I assume the issue does not exist in the x86_64 build? Maybe you can start it in a terminal (so you can see stdout/stderr, use either MSYS2 or the Maybe you can also share your Syncthing Tray config so I could at least rule out issues relating to features you don't have enabled. Maybe you can find an easier way to reproduce the issue, e.g. maybe suspending and resuming the system triggers the issue (without waiting a whole night)? If that's the case maybe the code to suppress notifications after the system has just been resumed is at fault. Otherwise I'm afraid I cannot really help much with this issue as I don't have a way to reproduce it myself. |
I can use task scheduler to run it after unlock. It' s just it doesn' t auto connect after start with the auto connect option checked, I have to manually connect. Config:
|
Ok, so it does not crash or otherwise exists early. The only problem is that Syncthing Tray does not auto-connect to Syncthing when resuming from standby. Am I now getting the problem correctly? The settings look correct for this to happen so this must be a bug then. I can try to reproduce it locally when I have time. Maybe this is related to the launcher not being able to use Boost.Process (so it uses QProcess and those code paths aren't regularly tested). It the output of Syncthing shown correctly in the launcher and in particular is the GUI listening address shown? Note that Syncthing Tray ignores the unavailability of Syncthing the first 15 seconds ( There's also a different experiment you could do which might be useful: Does it work when you disable |
No. It crashes. I just try to auto start it with task scheduler. I will try your proposals. |
|
Ok, then |
As the build itself is provided I'm closing this issue in favor of #304. |
Relevant components
syncthingctl
)libsyncthing
)Is your feature request specific to a certain platform/environment? Please specify.
Windows on arm
https://www.qt.io/blog/qt-for-windows-on-arm don' t know how hard it is.
The text was updated successfully, but these errors were encountered: