wxWidgets 3.1.5 does not build in xCode 8.3 using release schema (Issue #22227)
guzmanpaco
Describe the problem
We tried to use wxWidgets 3.1.5 source code to build and link wxWidgets on xCode 8.3 on Mac OS 10.12 for our project. It does not compile using Release schema.
To Reproduce
-
Perform build steps described in wxWidgets Github (../configure --enable-debug, make)
https://github.com/wxWidgets/wxWidgets/blob/master/docs/osx/install.md -
Create new project in xCode
-
Add wxcocoa xCode project of wxWidgets to project (build/osx/wxcocoa.xcodeproj)
-
Update project's settings to include the following frameworks:
a. libwx_osx_cocoa_static.a
b. QuartzCore.Framework
c. CoreFoundation.Framework -
Create Release schema (Change debug setting to release)
-
Perform Build using Release schema and Debug Schema
Patch or snippet allowing to reproduce the problem
N/A. Default generated code by xCode can replicate the issue.
Expected vs observed behaviour
Expected:
Application builds correctly.
Actual:
Application encounters build error on Release schema (Static was building using 1778 files on Release, 889 files on Debug).
Build error on:
core/graphics.cpp
"Non-constant-expression cannot be narrowed from type 'double' to 'CGFloat' (aka 'float') in initializer list" on line 917 CGSize s = { static_cast(f),f };
This is not encountered on Mac OS 11.4 using xCode 13. 3.1.6 on master branch does not encounter this issue (has a different issue with static not having volume.mm)
A clear and concise description of what the bug is.
Build error occurs using release schema on xCode 8.3 (xCode 8.3 and OS 10.12 are officially supported). Issue is not encountered on xCode 10.13.
Platform and version information
wxWidgets version you use: 3.1.5 (Release using source code tar)
wxWidgets port you use: wxOSX
OS and its version: macOS 10.12.6
Compiler being used: xCode 8.3, macos10.12
Attached zip containing:
- Configure log
- Make log
- Build Log from xCode
logs.zip
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Igor Korot
Describe the problem
We tried to use wxWidgets 3.1.5 source code to build and link wxWidgets on xCode 8.3 on Mac OS 10.12 for our project. It does not compile using Release schema.
To Reproduce
Perform build steps described in wxWidgets Github (../configure --enable-debug, make)
https://github.com/wxWidgets/wxWidgets/blob/master/docs/osx/install.mdCreate new project in xCode
Add wxcocoa xCode project of wxWidgets to project (build/osx/wxcocoa.xcodeproj)
Update project's settings to include the following frameworks:
a. libwx_osx_cocoa_static.a
b. QuartzCore.Framework
c. CoreFoundation.FrameworkCreate Release schema (Change debug setting to release)
--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/issues/22227%40github.com.
VZ
For the record, the actual error is
wxWidgets-3.1.5/src/osx/carbon/graphics.cpp:917b22: error: non-constant-
expression cannot be narrowed from type 'double' to 'CGFloat' (aka 'float') in initializer list [-Wc++11-narrowing]
CGSize s = { f, f };
^
and the reason we didn't see it is that it only happens in 32 bit builds (the report doesn't mention it, but the build log contains -arch i386).
I'm going to fix it, but I have to ask whether you're building in 32 bits on purpose. There should be really no reason to do it in 2022...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Actually I can't even build in 32 bits myself any more because there is no more i386 version of libSystem.tbd in any SDK version I still have and so I can't even run configure successfully.
Maybe we should just document that i386 is not supported any more?
@guzmanpaco If you still actually need 32 bit support, please consider contributing a PR making all the necessary changes, i.e. replacing double with CGFloat not just here but in any other places where it might be needed. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Lauri Nurmi
It appears that there are a bunch of other errors with 32-bit compilation in two other files, and at least the ones in webview_webkit.mm do not seem very trivial to fix.
Here are some examples (not a complete list):
../src/osx/cocoa/filedlg.mm:56:19: error: inconsistent number of instance variables specified
wxArrayString m_extensions;
^
../src/osx/webview_webkit.mm:52:25: error: attempting to use the forward class 'WKWebView' as superclass of 'WXWKWebView'
../src/osx/webview_webkit.mm:61:49: error: cannot find protocol declaration for 'WKNavigationDelegate'; did you mean 'NSAnimationDelegate'?
../src/osx/webview_webkit.mm:70:41: error: cannot find protocol declaration for 'WKUIDelegate'; did you mean 'WebUIDelegate'?
../src/osx/webview_webkit.mm:80:45: error: no type or protocol named 'WKURLSchemeHandler'
../src/osx/webview_webkit.mm:90:50: error: no type or protocol named 'WKScriptMessageHandler'
../src/osx/webview_webkit.mm:125:5: error: unknown type name 'WKWebViewConfiguration'
The last Mac with 32-bit-only CPU was Mac mini from 2006, according to a source.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@csomor Do you think it's worth trying to make 3.2 build for i386 or should we just officially drop support for it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
guzmanpaco
@vadz, we would like confirmation if i386/32 bit is officially dropped on 3.1.5 and 3.1.6? Our understanding on your edit on d369594 is that it is officially dropped.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
@csomor Do you think it's worth trying to make 3.2 build for i386 or should we just officially drop support for it?
with the raise to macOS 10.10 we can safely assume we are on a 64 bit booted system, so I think we just drop it
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
IME people typically use 32 bit build because they are using some closed source library that is only available in 32 bits. So I can sympathize with them and if anybody wants to try fixing 32 bit build before 3.2, I think we should accept their patches/PRs. But personally I am just unable to build anything in 32 bits at all, so I'm not doing to do anything about it and if it isn't fixed until 3.2.0, I think it's a pretty safe bet that nobody cares about it enough to do it and that it will never happen.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
getting rid of 32 also means that we'll always have version 2.0 of Objective-C runtime available ... tempting ... and no app with 32 bit will run higher than on mac 10.14, so I guess they need the 64 bit version of the lib anyway
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
guzmanpaco
Hi.
I would like to request official confirmation for the following:
- Is 32 bit support officially dropped on 3.1.6/3.1.7 and 3.2.0 on Mac?
- Is my understanding correct that Windows 32 bit will still be supported on 3.1.6/3.1.7 and 3.2.0
Thank you
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
- Unless someone feels very strongly about repairing it (which includes being able to test it), yes.
- Yes, we still support 32 bits under Windows because Microsoft, unlike Apple, doesn't actively try to break compatibility at any opportunity, so it doesn't cost us anything to do it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #22227 as completed via 5e1f491.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.