4 ms·

Ah, that's exactly the problem I had with synergy really. Randomly failing -- not terribly nice when one uses it for work. Mine takes peanuts for resources, an

Ah, that's exactly the problem I had with synergy really. Randomly failing -- not terribly nice when one uses it for work. Mine takes peanuts for resources, and I have uptimes of weeks or more on my machines. My current setup is a 'mac' with a 4K screen and a magic touchpad, and a bigass linux workstation alongside, with a 4K screen also. This one has no keyboard or mouse, and never had! Feel free to ping me if you need any help, I know it doesn't handle all the scenarios, but with a bit of incentive I'd be very happy to work on it a bit more! Right now It Works(TM) ;-)

morganvachon 8y ago
> Right now It Works(TM) ;-) That's exactly what I need, no more. :-) I'm at home now, I think I may test it out on another very old laptop with Slackware. I may even dig my OpenBSD laptop out of the closet and see if I can compile it for that platform. My only Mac right now is a C2D mini with 10.6 so I hope it will compile and run there. +++ So I just tried to compile on my Elementary OS workstation and got a few errors even after meeting all (I think) of the dependencies. I'm not a programmer beyond the occasional bash script, so I probably missed something somewhere. I have ruby, graphviz, and exuberant-ctags installed, and the usual basic build tools for a Debian based OS. Here's an example of an error, there were a few different ones with the same format: src/ts_mux.c: In function ‘data_start’: src/ts_mux.c:339:2: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(r->socket, msg, strlen(msg)+1);
- buserror 8y ago
  Ah, that must be ubugtu derivative with -Werror by default I suppose? That's your problem, it's a pedantic warning ar best, not an error.
  - morganvachon 8y ago
    Yep, Elementary is based on Ubuntu 16.04. Unfortunately it's not completing the build. I get this: cc1: all warnings being treated as errors and cc: error: obj-x86_64-linux-gnu/touchstream.o: No such file or directory cc: error: obj-x86_64-linux-gnu/ts_signal.o: No such file or directory cc: error: obj-x86_64-linux-gnu/ts_mux.o: No such file or directory Error: cc -o obj-x86_64-linux-gnu/touchstream.bin obj-x86_64-linux-gnu/touchstream.o obj-x86_64-linux-gnu/ts_display.o obj-x86_64-linux-gnu/ts_signal.o obj-x86_64-linux-gnu/ts_master.o obj-x86_64-linux-gnu/ts_clipboard.o obj-x86_64-linux-gnu/ts_display_proxy.o obj-x86_64-linux-gnu/ts_mux.o obj-x86_64-linux-gnu/ts_xorg_keymap.o obj-x86_64-linux-gnu/ts_xorg_client.o -lpthread -lX11 -lXtst -lXfixes -lXext -Wl,--relax,--gc-sections touchstream Done No binaries are created. I'll try it on a Slackware box, I usually never have odd issues building from source on that OS. +++ Thanks to j1elo above, I modified the Makefile.common and removed the -Werror CFLAG, and it compiled successfully. Now to do the same on the Mac and see what I get. :-)
- j1elo 8y ago
  Edit Makefile.common and remove -Werror from there. This is a widespread mistake, using -Werror unconditionally. This flag forbids all warning messages from the compiler, no matter how superficial the actual issue is. -Werror is a very good tool to use during development, i.e. for private (Debug) builds, but it should be disabled for publicly released code (aka Release), or at least a shortcut should always be provided for people who are not interested in editing the code, only in compiling it (e.g. maintainers). New warnings are added every day so to speak, so with -Werror you never know if your code will stop compiling any time soon. But sadly not many people account for that in their Makefiles.
  - morganvachon 8y ago
    Gotcha, thanks! I'll give it a whirl. +++ And it worked! Thanks for that! I'll file that in my notes for building on Ubuntu and derivatives for the future.
    - j1elo 8y ago
      You'd better write it in the compiler-specific notes! ;-) As I said, new warnings are added to each new version of the compiler, that's why -Werror is dangerous for code that is intended to keep compiling without changes. The unused-result warning was added in GCC 4.5, I bet in some of those older distros you can try and it will compile just fine, because they come with GCC 4.4 or older... Likewise, probably the author used an sufficiently old GCC version when this code was written.
      - morganvachon 8y ago
        Got it. As I said I'm certainly not a developer but you've given me a lot of great info here. I do a good bit of compiling from source on Slackware for packages not available in the official or third party repos, and I've rarely had build issues similar to this one. Now I know one more thing to look for. Thanks again!

morganvachon 8y ago

> Right now It Works(TM) ;-) That's exactly what I need, no more. :-) I'm at home now, I think I may test it out on another very old laptop with Slackware. I may even dig my OpenBSD laptop out of the closet and see if I can compile it for that platform. My only Mac right now is a C2D mini with 10.6 so I hope it will compile and run there. +++ So I just tried to compile on my Elementary OS workstation and got a few errors even after meeting all (I think) of the dependencies. I'm not a programmer beyond the occasional bash script, so I probably missed something somewhere. I have ruby, graphviz, and exuberant-ctags installed, and the usual basic build tools for a Debian based OS. Here's an example of an error, there were a few different ones with the same format: src/ts_mux.c: In function ‘data_start’: src/ts_mux.c:339:2: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result] write(r->socket, msg, strlen(msg)+1);

buserror 8y ago
Ah, that must be ubugtu derivative with -Werror by default I suppose? That's your problem, it's a pedantic warning ar best, not an error.
- morganvachon 8y ago
  Yep, Elementary is based on Ubuntu 16.04. Unfortunately it's not completing the build. I get this: cc1: all warnings being treated as errors and cc: error: obj-x86_64-linux-gnu/touchstream.o: No such file or directory cc: error: obj-x86_64-linux-gnu/ts_signal.o: No such file or directory cc: error: obj-x86_64-linux-gnu/ts_mux.o: No such file or directory Error: cc -o obj-x86_64-linux-gnu/touchstream.bin obj-x86_64-linux-gnu/touchstream.o obj-x86_64-linux-gnu/ts_display.o obj-x86_64-linux-gnu/ts_signal.o obj-x86_64-linux-gnu/ts_master.o obj-x86_64-linux-gnu/ts_clipboard.o obj-x86_64-linux-gnu/ts_display_proxy.o obj-x86_64-linux-gnu/ts_mux.o obj-x86_64-linux-gnu/ts_xorg_keymap.o obj-x86_64-linux-gnu/ts_xorg_client.o -lpthread -lX11 -lXtst -lXfixes -lXext -Wl,--relax,--gc-sections touchstream Done No binaries are created. I'll try it on a Slackware box, I usually never have odd issues building from source on that OS. +++ Thanks to j1elo above, I modified the Makefile.common and removed the -Werror CFLAG, and it compiled successfully. Now to do the same on the Mac and see what I get. :-)
j1elo 8y ago
Edit Makefile.common and remove -Werror from there. This is a widespread mistake, using -Werror unconditionally. This flag forbids all warning messages from the compiler, no matter how superficial the actual issue is. -Werror is a very good tool to use during development, i.e. for private (Debug) builds, but it should be disabled for publicly released code (aka Release), or at least a shortcut should always be provided for people who are not interested in editing the code, only in compiling it (e.g. maintainers). New warnings are added every day so to speak, so with -Werror you never know if your code will stop compiling any time soon. But sadly not many people account for that in their Makefiles.
- morganvachon 8y ago
  Gotcha, thanks! I'll give it a whirl. +++ And it worked! Thanks for that! I'll file that in my notes for building on Ubuntu and derivatives for the future.
  - j1elo 8y ago
    You'd better write it in the compiler-specific notes! ;-) As I said, new warnings are added to each new version of the compiler, that's why -Werror is dangerous for code that is intended to keep compiling without changes. The unused-result warning was added in GCC 4.5, I bet in some of those older distros you can try and it will compile just fine, because they come with GCC 4.4 or older... Likewise, probably the author used an sufficiently old GCC version when this code was written.
    - morganvachon 8y ago
      Got it. As I said I'm certainly not a developer but you've given me a lot of great info here. I do a good bit of compiling from source on Slackware for packages not available in the official or third party repos, and I've rarely had build issues similar to this one. Now I know one more thing to look for. Thanks again!