Skip to content
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

macOS 1.11 error symbol not found: _clock_gettime with syncthing 1.14.0 #148

Closed
schuetzm opened this issue Mar 2, 2021 · 16 comments
Closed

Comments

@schuetzm
Copy link

schuetzm commented Mar 2, 2021

I'm using syncthing-macos 1.6.1-1 on Mac OS X (El Capitan, 10.11.6). Today, Syncthing updated itself to version 1.14.0. Now the syncthing binary crashes on startup:

dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /Users/schuetzm/Library/Application Support/Syncthing-macOS/./syncthing
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime
  Referenced from: /Users/schuetzm/Library/Application Support/Syncthing-macOS/./syncthing
  Expected in: /usr/lib/libSystem.B.dylib

It seems this is caused by building syncthing on a newer MacOS and not setting MACOSX_DEPLOYMENT_TARGET. See https://bugs.erlang.org/browse/ERL-256 for details.

So... is this even the right place to submit the bug? I.e., are you building your own syncthing binaries, or should I report it upstream?

@xor-gate
Copy link
Member

xor-gate commented Mar 2, 2021 via email

@majorcode
Copy link

majorcode commented Mar 2, 2021

I'm experiencing this problem too. It's an old Mac server that can not be upgraded past 10.11.6. Is there a way to forcibly run an older build of Syncthing on machines that can't be upgraded? Even if that only buys some time to decommission the old machine?

@majorcode
Copy link

majorcode commented Mar 2, 2021

I found the quick fix I was looking for. Setting STNOUPGRADE=1 in the env (I actually just added it to the command line) stops Syncthing from upgrading. Also note that old versions of the Syncthing binary are saved during the auto upgrade. They will have one or more .old extentions added to the file name. Be sure to run the one that still works on your OS. The latest version I can run is 1.13.1

I don't expect this to work forever. But at least I can run sync while I figure out how to get the new server installed.

@xor-gate
Copy link
Member

xor-gate commented Mar 2, 2021

You could manually install the bundle v1.12.1-1 which has the STNOUPGRADE=1 set by default. Since v1.13.0 syncthing is build with golang 1.16 due to introduction of Apple M1 silicon CPU.

@xor-gate
Copy link
Member

xor-gate commented Mar 2, 2021

Please let me know if it works then we can close this issue. I added some notes in the v1.12.1-1 and v1.13.0 releases.

xor-gate added a commit that referenced this issue Mar 2, 2021
Add macOS version support for releases (see #148)
@johnblommers
Copy link

I found the quick fix I was looking for. Setting STNOUPGRADE=1 in the env (I actually just added it to the command line) stops Syncthing from upgrading. Also note that old versions of the Syncthing binary are saved during the auto upgrade. They will have one or more .old extentions added to the file name. Be sure to run the one that still works on your OS. The latest version I can run is 1.13.1

I don't expect this to work forever. But at least I can run sync while I figure out how to get the new server installed.

I tried your workaround. I had to launch STNOUPGRADE=1syncthing.old.old but it worked for now.

I hope that the developers don't shut the door on macOS El Capitan over this.

@martinackerl
Copy link

Same issue here. I am running Syncthing on MacOS 10.11.6.
v1.13.1 works.
v1.14.0 gives the error Symbol not found: _clock_gettime

I hope v1.13.1 will still interoperate with newer versions for some time.
Is there a roadmap?

@imsodin
Copy link
Member

imsodin commented Mar 4, 2021

The road-map is whatever go does, which is documented here: https://tip.golang.org/doc/go1.15#darwin

Go releases happen once every 6 months: https://github.com/golang/go/wiki/Go-Release-Cycle

Interoperability: Any instance running a v1 version is intended to be able to sync with any other running v1. That doesn't mean that there won't be problems. Plus new Syncthing versions aren't just for show, they have bugfixes and improvements -> do upgrade.

tl;dr: Time to upgrade your OS.

@martinackerl
Copy link

tl;dr: Time to upgrade your OS.

I know, I know, unfortunately it's not possible on my otherwise well-working computer.
But I am not complaining here, thats not your fault ;)

@xor-gate xor-gate changed the title Symbol not found: _clock_gettime macOS 1.11 error symbol not found: _clock_gettime with syncthing 1.14.0 Mar 4, 2021
@xor-gate
Copy link
Member

xor-gate commented Mar 4, 2021

According to wikipedia:

  • macOS 10.11 is unsupported since September 2018
  • macOS 10.12 is unsupported since October 2019
  • macOS 10.13 is unsupported since December 2020

The "problem" with golang new releases is it tracks latest support states of its supported os versions. And will also drop support when vendors do so. So for Syncthing and Syncthing-macos this basicly means no support for 1.11 when installing higher versions than v1.12.1-1 . I'm not 100% sure why @martinackerl says v1.13.0 works on macOS 1.11.

For my own reference we should also notify the Sparkle updater the minimum required macOS version so the auto-updater doesn't try to update not-supported version. See https://sparkle-project.org/documentation/publishing/ section Minimum system version requirements.

Could somebody test and report if the v1.13.0 bundle works?

@johnblommers
Copy link

Apple has this frustratingly draconian attitude that perfectly good-working Macintosh hardware is to be declared as vintage/obsolete/legacy. Why do you suppose I'm still running macOS El Capitan 10.11.x? Because Apple won't let me update to the most recent OS.

Now Syncthing has fallen in with this damnable attitude? We follow where Go treads? Just a moment. This is an open source project. We're better than Apple and Google.

It's my expectation that Syncthing continues to self-update and work properly. Otherwise it should do a quick check and disable automatic updating. The current behavior to brick itself isn't cool.

Ironically I could pave the Macintosh boot device with Linux and keep running the current version of Syncthing. Oh, wait.

BTW I downloaded the most recently available v1.13.x macOS binary from archive.org. The Syncthing downloads page only reveals the most current build, which breaks due to the missing symbol.

@imsodin
Copy link
Member

imsodin commented Mar 5, 2021

If you really feel like you want to open a discussion on supporting old infrastructures of a particular platform, do that on https://forum.syncthing.net (though I personally prefer you wouldn't, my statement will be brief). The issue tracker is for tracking actionable issues, not wide-ranging discussions.

@martinackerl
Copy link

@xor-gate

Could somebody test and report if the v1.13.0 bundle works?

I can definitely confirm that [v1.13.1] works on MacOS 10.11.6.
I have it running on 3 different machines on 10.11.6.
I use the syncthing-macos: macOS application bundle from syncthing.net
screenshot

@johnblommers
Copy link

johnblommers commented Mar 5, 2021

The issue tracker is for tracking actionable issues, not wide-ranging discussions.

Agreed. The comments in this issue helped me continue using Syncthing on my Early-2008 Mac Pro. Thanks all for your constructive comments.

Also I confirm that v1.13.1 works on MacOS 10.11.6 El Capitan

@xor-gate
Copy link
Member

xor-gate commented Mar 6, 2021

Thanks all for the feedback.

@amark
Copy link

amark commented Mar 14, 2023

THANK YOU this worked, using an older version. Phew! Deeply appreciated - forced to switch off Dropbox because its also won't run on my laptop anymore with no way to rollback, at least syncthing does! Thank you thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants