Open devisbal opened 2 months ago
Hi,
I've made a i686-build, i.e. win32 (not win64) binary. I'm not sure , that it works on windows xp
, please try the attached files.
Let me know the outcome!
Hi:
I got the following error: syncspirit-daemon.exe - Entry Point Not Found The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL 32. dll.
GetTickCount64 function: Minimum supported client Windows Vista So, there is not support for Windows XP. I did not see this used on your source, so it should be part of one of the external lib or mod used.
BR
What I have found that my compiler (mingw) is most likely compiled with default target to windows vista. It is something like that:
So, if you can build mingw on yourself (on linux machine) it should probably work, because I was able to compile it.
Here are a few patches:
diff --git a/src/utils/network_interface.cpp b/src/utils/network_interface.cpp
index 01558d8..034168d 100644
--- a/src/utils/network_interface.cpp
+++ b/src/utils/network_interface.cpp
@@ -115,8 +115,7 @@ static uri_container_t _local_interfaces(logger_t &log, std::uint16_t port) noex
// IPv4
SOCKADDR_IN *ipv4 = reinterpret_cast<SOCKADDR_IN *>(address->Address.lpSockaddr);
- char host[INET_ADDRSTRLEN] = {0};
- inet_ntop(AF_INET, &(ipv4->sin_addr), host, INET_ADDRSTRLEN);
+ auto host = inet_ntoa(ipv4->sin_addr);
auto full = fmt::format("tcp://{}:{}/", host, port);
auto uri = utils::parse(full).value();
r.emplace_back(std::move(uri));
--- a/src/osal.c
+++ b/src/osal.c
@@ -1090,7 +1090,7 @@ MDBX_INTERNAL_FUNC void osal_ioring_reset(osal_ioring_t *ior) {
for (ior_item_t *item = ior->pool; item <= ior->last;) {
if (!HasOverlappedIoCompleted(&item->ov)) {
assert(ior->overlapped_fd);
- CancelIoEx(ior->overlapped_fd, &item->ov);
+ CancelIo(ior->overlapped_fd);
}
if (item->ov.hEvent && item->ov.hEvent != ior)
ior_put_event(ior, item->ov.hEvent);
More building instructions u can find in doc/building.md
.
PS. You can find whether it need windows-vista via the command grep -a GetTickCount64 *.dll
will try to build the mingw compiler by myself, not sure that it will be successful :)
I could not find to patch: --- a/src/osal.c
-> % find . -iname 'osal.c'
./lib/mbdx/src/osal.c
I think I was able to build for windowx xp, but unfortunately libmbdx
reports some error during startup. I have asked the libmbdx author whether it is possible to add windows xp support. Will let u know
I'll try to use a different db-engine (switcheable) for winxp, but probably in a next version.
The engines under consideration are:
I think I've managed to do a proper build, please try @devisbal .
If it works, I'll do more official release v0.3.1
a bit later + instructions how to build.
Hi:
It did start. But you have configured it to connect to Global Discovery. I did not see any transfer. We do use defined direct connection to the SyncThing Server. [IP:port] We do not have a Discover Server either. Info output for the test. Test.txt
I would like to start reviewing source and analyze to provide changes, but I will need that you help me with the cross compiler that you are using. I have not been able to create it.
Also, when I did try conan on a linux sysmtem with the i686-mingw , when trying conan to process zlib, I did got errors about using m-m64, and not working.
BR
We do use defined direct connection to the SyncThing Server. [IP:port] We do not have a Discover Server either.
This is correct sync-spirit
behavior, as the "direct discovery" feature not implemented , please file a separate issue. Only relay/global/local discoveries work.
However, you can take the device id and ip address from sync-spirit
and copy it to other client... and it will connect to syncthing and the sync should start.
I would like to start reviewing source and analyze to provide changes, but I will need that you help me with the cross compiler that you are using. I have not been able to create it.
Sure, here are the steps
pip install conan
)settings.mk
you have MXE_TARGETS := i686-w64-mingw32.static
MXE_PLUGIN_DIRS=plugins/windows-xp
make lua
, and copy lua.exe to your win-xp host and check that it launches.i686-w64-mingw32.static-gcc
should be foundxp
conan profile at ~/.conan2/profiles/xp
xp.txtcd syncspirit
mkdir build.xp
cd build.xp
conan install --build=missing -o '*:shared=False' -o shared=False --output-folder . -s build_type=Release --profile:build=default --profile:host=xp ..
sync-spirit
can be configured & buildsource ./conanbuild.sh
cmake .. -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=$PWD/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-D_WIN32_WINNT=0x0501"
make -j`nproc`
PS. I've created wixp-support
branch with yet not committed changes to let it build.
Hi: Question: What Linux version do you use for building the WinXP version? BR
Question: What Linux version do you use for building the WinXP version?
it does not matter, any modern should be ok. I use void-linux :)
Hi:
I did try on ubuntu and also void-linux. On both I got the same error when trying to generate gtk3 error at gtk3.txt BR
Which command did you issued and in which dir? It seems you are trying just to do make
for the whole mxe
...
make lua
should be enough.
I've made a v.0.3.1
release. Basically it is the same as the attached exe here. Also building instructions have been updated (basically the same as here).
WBR
Hi:
I finally believe I was able to generate it. But I got the following error.
[E/2868] ssdp, udp socket cancellation : The attempted operation is not supported for the type of object referenced
Hi:
I did use the one on your site and that do not generate the error. [syncspirit-daemon_v0.3.1_i686-win32.zip] Did you use the wixp-support branch?
BR
Hi:
I just rebuild with the new instruction sequence from master, and it did work.
Thanks BR
[E/2868] ssdp, udp socket cancellation : The attempted operation is not supported for the type of object referenced
BOOST_ASIO_ENABLE_CANCELIO=1
that thing does the job right :)
Hi: I build a lab with my own "discovery server". Plus: One linux syngthing and one windows syncspirit. Now the problem I nned to resolve is with the synxspirit and the entry for add_folder:label=Test:id=Test:path=M:/Test I have a disk M: om Windows where I want it to do the work, but instead it is using the path for where syncspirit is installed, creating a folder M I'm doing something worng? What should I have to use to got the use of disk M:
BR
Hi,
I think there was a bug that dir scanning wasn't triggered. I fixed that in v0.3.2, please try. Also I specified path at Z:\\test
, you can also try z:\test
and other variants with normal slash.
Hi,
I did try all combinations: M;\Test M:\Test M:/Test M://Test and always all ended bad in SyncSpirit/M It's started with: syncspirit-daemon --log_level debug --config_dir=D:/SyncSpirit/Data --command add_peer:ub22syncthing:CL76FF7-JN2UIZN-ZKVV6SZ-FYKFNH3-VMGUSD5-RZUPOHY-WUKP4P2-44FOVQ5 --command add_folder:label=Test:id=Test:path=M:/Test --command share:folder=Test:device=CL76FF7 --command inactivate:120
[2024-05-11 22:11:17.969] [I/268] starting syncspirit v0.3.2, libraries: protobuf v3.21.9, lz4: v1.9.4, OpenSSL OpenSSL
1.1.1s 1 Nov 2022
...
[2024-05-11 22:11:19.094] [D/268] controller/CL76FF7, next_file = test.txt
[2024-05-11 22:11:19.094] [D/268] CL76FF7/tcp/10.2.0.185:22000, read_controlled, std::unique_ptr<syncspirit::proto::Resp
onse, std::default_delete
Where the other paths like --config-dir did works.
Oh, it was windows-specific bug in my code, as it parsed :
as parameters separator. Now it should be fixed, please try v0.3.3
Hi,
Yas, it's working now. Files did go to M:\Test Now what is happening is if I do restart syncspirit now got: [C/3680] conflict handling is not available for = Test/test.txt, 'cf156ab6c11aee0b:0' vs '12ffe297e96ea88c:1714788860'
Also: Also I think that the DB at: \SyncSpirit\Data\mbdx-db do not get clered after a file that was deleted from origen syncspitit beleive they should get it again.
[D/2332] controller/CL76FF7, next_file = Live.mp4
Restarted syncspirit and got: [C/2516] conflict handling is not available for = Test/Live.mp4, '12ffe297e96ea88c:1715548576, cf156ab6c11aee0b:17 15548577' vs '12ffe297e96ea88c:1715548657'
this is expected behavior: when you delete a file on one device, and modify it on another, and then try to sync them, the 1st device does not knows what to do. It is a conflict, and it have to be resolved manually.
The same conflict situation is on syncthing. There are a few strategies to handle them: either push-only (i.e. ignore remote deletes/changes) changes or pull-only changes (i.e. ignore local deletes/changes), or make a conflict file for manual conflict resolution (default)
Neither of them is currently implemented in syncspirit, this is for future development.
Hi:
It will be possible to build for 32bits Windows XP this program syncspirit? We do have been using SyncThing on Windows XP, but those just are the latest posible we could compile/build that was: V1.6.1
BR