wails
wails copied to clipboard
wails build throwing error after updating to wails v2.4.1 in mac version 10.14.6(Mojave)
Description
After updating to wails 2.4.1 version in mac version 10.14.6(Mojave), while compiling the wails project we are receiving the following the error: *WailsContext.m:221:28: error: property 'fraudulentWebsiteWarningEnabled' not found on object of type 'WKPreferences '
*INFO Build command: go build -a -tags desktop,wv2runtime.download,production -ldflags "-w -s" -o /Users/mactest/Desktop/tray/polaris/epsticket/build/bin/epsticket • Environment:%!(EXTRA string=TERM=xterm-256color SHELL=/bin/bash _INTELLIJ_FORCE_SET_GO111MODULE=on TMPDIR=/var/folders/l6/_bn6cq8173d3clfy4wfm26jw0000gn/T/ Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.PIkNolvTtL/Render _INTELLIJ_FORCE_PREPEND_PATH=/usr/local/go/bin:/Users/mactest/go/bin: TERM_SESSION_ID=4ba74d8c-6591-44b5-9ced-a276ff7e604f USER=mactest SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.TZ94kEJNOq/Listeners __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 GO111MODULE=on PATH=/usr/local/go/bin:/Users/mactest/go/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/Users/mactest/.meteor:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin TERMINAL_EMULATOR=JetBrains-JediTerm _INTELLIJ_FORCE_SET_GOROOT=/usr/local/go PWD=/Users/mactest/Desktop/tray/polaris/epsticket _INTELLIJ_FORCE_SET_GOPATH=/Users/mactest/go XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 SHLVL=1 HOME=/Users/mactest GOROOT=/usr/local/go LOGNAME=mactest LC_CTYPE=en_IN.UTF-8 GOPATH=/Users/mactest/go OLDPWD=/Users/mactest/Desktop/tray/polaris/scripts _=/Users/mactest/go/bin/wails CGO_CFLAGS=-mmacosx-version-min=10.13 CGO_CXXFLAGS=-I/Users/mactest/Desktop/tray/polaris/epsticket/build CGO_ENABLED=1 CGO_LDFLAGS=-mmacosx-version-min=10.13 GOOS=darwin GOARCH=amd64)# github.com/wailsapp/wails/v2/internal/frontend/desktop/darwin WailsContext.m:221:28: error: property 'fraudulentWebsiteWarningEnabled' not found on object of type 'WKPreferences ' ERROR exit status 2 ERROR exit status 2 :hearts: If Wails is useful to you or your company, please consider sponsoring the project: https://github.com/sponsors/leaanthony
Please suggest me what to do.
To Reproduce
Build a wails application using mac version 10.14.6(Mojave)
Expected behaviour
There should be no error while compiling the code.
Screenshots
No response
Attempted Fixes
No response
System Details
Wails CLI v2.4.1
Scanning system - Please wait (this may take a long time)...Done.
# System
OS | MacOS
Version | 10.14.6
ID | 18G9323
Go Version | go1.19.4
Platform | darwin
Architecture | amd64
# Wails
Version | v2.4.1
# Dependencies
Dependency | Package Name | Status | Version
Xcode command line tools | N/A | Installed | 2354
npm | N/A | Installed | 8.5.0
*Xcode | N/A | Available |
*upx | N/A | Available |
*nsis | N/A | Available |
* - Optional Dependency
# Diagnosis
Your system is ready for Wails development!
Optional package(s) installation details:
- Xcode: Available at https://apps.apple.com/us/app/xcode/id497799835
- upx : Available at https://upx.github.io/
- nsis : More info at https://wails.io/docs/guides/windows-installer/
:hearts: If Wails is useful to you or your company, please consider sponsoring the project:
https://github.com/sponsors/leaanthony
Additional context
No response
Looks like we might need a version guard here @stffabi
That's strange as there is one for 10.15+
https://github.com/wailsapp/wails/blob/284e20a2905e694722b0e2b79107b8a19752ce51/v2/internal/frontend/desktop/darwin/WailsContext.m#L224-L226
@kishorkumar287 - any further updates? Have you tried the latest builds?
@leaanthony @stffabi hello, how about this bug? I've suffered the same problem.
Unfortunately I don't have such an old system available to find a workaround. There's also a macOS 10.15+ version guard there, which should handle that. I have no idea why macOS 10.14 tries to include that. If anyone finds out why the guard does not work and is able to fix it, we happily going to include that.
Just as a side note, Go is about to drop support for macOS 10.14 and older.
Go 1.20 is the last release that will run on macOS 10.13 High Sierra or 10.14 Mojave. Go 1.21 will require macOS 10.15 Catalina or later.
I may be totally stupid - it's 2am here - but as I'm getting really annoyed by this issue I had to make sure:
Wails use Objective C for building its mac runtime correct? If that the case I think the @available don't behave as we expect:
https://developer.apple.com/documentation/swift/marking-api-availability-in-objective-c
So @available is like the #available for Swift (if I read this documentation correctly), a runtime check, not a compilation one. This will explain why the guard (@available) is not triggered (I'm targeting 10.13)
Answering my own question as I cannot find an obvious way to make API_AVAILABLE/@available works with a statement at compile time. Should I compile with a SDK based on MacOS 10.15 but targeting 10.13 as the minimum version? The idea is that if the compilation works (hopefully) the runtime check will not trigger the problematic code when the code run. Maybe that the Apple way of doing it?
It's a bit too late for me to try it now but I will give it a shot tomorrow.
Continuing from yesterday: I need to run more test - but I think that the correct flow: @available will not perform a check at compile time but at runtime. So in order to successfully compile we need to use the SDK corresponding to the highest version defined in @available - Currently in Wails 2.60 that should be MacOS 10.15. Then we can use "-mmacosx-version-min" to set the minimum compatible version (this one can be lower than the SDK). I ran a test with the SDK from MacOS 10.15 and I targeted 10.13. Compilation & linking was successful (I didn't yet tried the binary on a 10.13)
Also on a side note Go drop support for 10.13 in 1.21 - I'm currently using 1.20.10 for this reason - not sure if that has an impact on the compilation.
If all my assumptions are correct it will be good idea to update Wails' doc to add the minimum MacOS version to use for development and the minimum MacOS version that can be targeted (where the runtime will run). I'm suspecting that for dev we need a 10.15 and a 10.13 for deployment at minimum.