I’ve been using syncthing for a few months on my Mac without problem. Noticed over the last week or so that it was no longer running in the background. I looked at the syncthing-errors.log and found this:
dyld: Symbol not found: _SecCertificateCopyNormalizedSubjectContent
Referenced from: /Users/myusername/bin/syncthing
Expected in: flat namespace
Help. I have no clue how to fix this. My best guess is this looks like some object linking didn’t properly happen on an update build and some internal symbol is no longer found. Or the executable references a different library I don’t have installed? Or… ???
User Perspective Defensive Caveat: I’m fearful of the answer, “Oh, yea, your old stuff is the problem” because that discards anybody who doesn’t upgrade. More pointedly, I changed nothing after 7 months or so of success and things silently failed and that breaks trust.
Mac Snow Leopard 10.6.8. Not sure how to determine the Syncthing version without running. The executable is 14.9 MB dated July 26th, and errors immediately after running at the command line. Syncthing v0.14.32 (14.8 MB dated July 11th works fine) starts up and prints all the normal information, and then gives the same error after auto-upgrading to v0.14.33 and restarting in 1 minute. (syncthing is renamed to syncthing.old and new 14.9 MB syncthing file appears).
Unfortunately, your old stuff is the problem. Specifically, Go programs like Syncthing require 10.8 or newer and this has been the case for at least a year.
That said, I think I know why the 0.14.32 version worked. I changed the build server between these two releases and didn’t copy one of the environment variables to make it a static binary on Mac. That may be technical mumbo jumbo but in short:
I’ll fix it so the next release should hopefully work again
Your system really is unsupported (by us and by Apple), Syncthing works just by luck, and you really should upgrade.
The 0.14.34rc build you provided appears to be working. So, if (even new) Macs needed the change you did, did others complain? If not, thank you for the unsupported support.
Running 0.14.34rc, I notice the log does say, “Automatic upgrade is always enabled for candidate releases.” When it auto-upgrades and breaks because Go requires a feature of 10.8, is there any way for me to use 0.14.32 and forbid an upgrade? I see only command line options to force upgrade, not to forbid upgrade.
I’ll try to use Syncthing as long as I can or fall back to my now ancient version of another sync program I can prevent upgrades for.
Philosophy:
I guess it’s relative viewpoint of a developer or user. As a developer, you keep on the edge of new, and old stuff looks old. To a user, what they have is what they have, and they look for software that will (continue to) work. I don’t think one is right or wrong.
There is pain to upgrade or not upgrade. I actually have a 10.7.5 Lion installation, but using that upgrade breaks other things I value having working. With my Win10 machine, it keeps trying to upgrade a USB/serial cable driver for which I require the old version.
Newer Macs do not need the fix I did. The fix will be in future builds as well so you do not need to prevent upgrades.
There is a difference, in my opinion at least, between “the edge of new” and a six versions old and completely unsupported operating system. We try to keep our system requirements reasonable, but this is not within the spectrum of reasonable (again, in my opinion).
New versions of Syncthing will continue to work on your installation, until they don’t. We won’t do anything intentionally to break it, we’ll bend slightly backwards to keep it working (like now), but we’re not testing for it and at some point some new requirement will probably make it break.
I know you need to answer the call for new versions. However, if an older system answers my requirements, it’s difficult to throw it in a landfill. There are some programs like Irfanview and Total Commander that have been with me for nearly 20 years. I value such stability.
Is there any way to prevent Syncthing from upgrading the version? I looked at GUI options and command line options and didn’t find any. The argument for providing new versions is more powerful than the argument for forcing new versions. Maybe a more nefarious way like blocking a certain port or URL?
I’m looking for any way to lock down a working configuration - for me, any upgrade advantage is less than the advantage of stability.
So I was running 0.14.34rc provided by Jakob and the Mac was happy again. However, on Aug 8th, the new 0.14.34 stable was released, which recreated the problem.
The “no upgrade” option is not available in the 0.14.34rc so my Mac tried to upgrade. But the Mac 0.14.34 was not available, so it “upgraded” back to stable release 0.14.33, which failed (original thread at top).
Now I have a race condition I can’t fix. If I run 0.14.34rc, it doesn’t offer a “no upgrade” option. If I run 0.14.32, it automatically upgrades before I can choose “no updates” in the GUI. Either way, I land at 0.14.33 which doesn’t work. Looks like I need to simply wait for 0.14.34.
[OCLV7] 07:53:58 INFO: Automatic upgrade is always enabled for candidate releases.
[OCLV7] 07:53:58 INFO: Starting usage reporting
[OCLV7] 07:53:59 INFO: GUI and API listening on 127.0.0.1:8384
[OCLV7] 07:53:59 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
…
[OCLV7] 07:54:02 INFO: Automatic upgrade: couldn’t find a release to download