For my iOS & OS X C++ Library, the data type unsigned long is causing problems in 64 bit environment. It works fine in 32 bit Architecture. In GCC read about -mx32 Compiler Flag, which will process all 64 bit data types as 32 bit. In iOS & OS X for llvm, does there exists any such Flags to support unsigned long as in 32 bit architecture.
I have tried adding -mx32 flag in Compliter Flags section, still size of unsigned long is printed as 8.
Thanks.
The size of long is defined by the platform ABI. Apple has announced that you must support their 64-bit ABIs:
64-bit Requirement for Mac Apps
At WWDC 2017, we announced new apps submitted to the Mac App Store must support 64-bit starting January 2018, and Mac app updates and existing apps must support 64-bit starting June 2018. If you distribute your apps outside the Mac App Store, we highly recommend distributing 64-bit binaries to make sure your users can continue to run your apps on future versions of macOS. macOS High Sierra will be the last macOS release to support 32-bit apps without compromise.
64-bit Apps on iOS 11
As a reminder, new iOS apps and updates submitted to the App Store must support 64-bit. Support for 32-bit apps is not available in iOS 11 and all 32-bit apps previously installed on a user’s device will not launch. If you haven’t updated your app on the App Store to support 64-bit, we recommend submitting an update so your users can continue to run your apps on iOS 11, which will be in the hands of hundreds of millions of customers this fall.
This means that going back to a 32-bit only build will not work in the near term. It is theoretically possible to build a custom compiler which has a 64-bit ABI on the outside, but different type sizes on the inside. OpenJDK does this internally, and the GNU toolchain supports something quite similar on x86-64 (although it still needs kernel support, so it's not an option for Darwin). But this is a lot of work, and requires lots of adjustments to system headers.
Unfortunately, your best bet is to replace unsigned long in your software with a portable type such as uint32_t.
Related
I'm working on a game using C++ and relying on legacy features of OpenGL.
I've mostly been doing programming on Windows machines and am now looking into expanding into Linux and Mac OS. As a personal challenge, I'd like to keep my software as backwards-compatible as possible and support as many OSes as possible. With Windows, I've been able to upkeep support for as low as Windows 95 (with Visual Studio giving me some trouble in the process but working it out nevertheless). However, I have next to no knowledge of Mac OS, having never used it myself until just now. Considering my software runs on Windows 95, it certainly does not require any advanced features on functions.
The lowest version of Mac OS that old versions of Xcode seems to support is 10.1.x. If I was to write software for this version of Mac OS, would it run on more modern versions of Mac OS? I've read that there are software patches that enable support for some older MacOS software on never versions but I would rather not inconvenience the end user like that.
I would not mind building two different versions of the software (say, a legacy and modern launcher) but having to build five or ten different versions of the software would be a massive pain and I'd rather avoid that if at all possible.
I apologize for my lack of knowledge in the field, my own research has only yielded very limited information and I would rather not waste weeks on a fruitless endeavor.
TL;DR: I want to write software in Xcode (C++) for Mac OSX that supports as many versions of the OS as possible. If I was to target Mac OS version 10.1, can I expect it to run on modern versions of Mac OS? If not, how much effort would it take to support as many versions of Mac OS as possible?
You're going to have to make a decision as to where you're going to cut off support, or you're going to have to build multiple versions of the app in different specially-built build environments.
Modern macOS (10.15) is strictly 64-bit x86-64 only, zero support for 32-bit apps. If you build on 10.15 you can't even build a 32-bit image. If you did it would be linked against libraries that don't exist on older versions of the OS.
Mac OS X 10.6 was the last 32-bit x86 version that shipped, but was also the first 64-bit version of the OS, as it represented the transition to 64-bit. It was also the last PowerPC version that shipped.
If you want to support PowerPC machines, which was the only option in the 10.1 days, you'll need a compatible system to build it.
Ecosystem-wise, most Mac users are able to run current versions of the OS. Anything 2012+ is still able to get current OS releases, which is a lot of hardware. Anything before that is a mix of 32-bit and PowerPC hardware, though you won't see a lot of people with systems like that in the wild.
In short, 10.15 is easy, 10.14 and 10.13 aren't going to be hard. Anything beyond that will be various degrees of challenging, but beyond 10.6 things will get super complicated.
One way to estimate popularity is things like the Steam Hardware Survey where the breakdown looks like this:
10.15: 31.6%
10.14: 34.1%
10.13: 14.8%
10.12: 5.7%
10.11: 3.7%
So the good news is things drop off pretty steeply after 10.13 and by 10.11 there's not many users running an OS that old.
Is it safe to assume that any x86 compiled app would always run under x64 edition of same OS the app was compiled in?
As far as I know, For Windows OS the answer is "Yes". Windows x86 emulation layer is built for the same purpose. But, I just want to reconfirm this from experts here.
What about Unix, Linux? Are there any caveats?
No, for x86 code to run it need to be run in compatibility or legacy mode. If the OS doesn't support running processes in compatibility mode the program would most likely not being able to run.
Linux and IFAIK Windows currently supports compatibility mode and it looks like many more are supporting it too, more or less. My understanding is that NETBSD requires a special module to support this, so it's not necessarily without special care that it will be supported and it shows that it's quite possible that there exists OS'es where the possibility has been dropped completely.
Then in addition there's the possibility of breaking the backwards compatibility in the future, that's already happened on the CPU as virtual x86 mode is no longer available from long mode that is you can't run 16 bits program anymore under 64-bit Windows or Linux.
It could also happen on the OS side, that the developers could decide not to support compatibility mode anymore. Note that this may also have happened as it might be possible to support virtual x86 mode by first switching to legacy mode, but if possible no-one seem to have bothered doing it. Similarly neither Windows or Linux developers seems to have bothered implementing possibility to run kernel code in legacy mode in 64-bit kernel.
The preceding two sections shows that there are future or even present indications on this might not always be possible.
Besides as this is a C++ question you would have to ask yourself the question why you would want to make such a assumption? If well written your code should be able to be compiled for 64-bit mode - for you haven't relied on data types being of specific width, have you?
No. We have a whole bunch of Debian servers which miss the Multi-Arch i386 (32 bits) libraries. On Windows Server Core, WoW64 (the 32 bit subsystem) is optional. So for both Linux and Windows, there are known 64 bit systems that won't run x86 executables.
My iOS app makes use of an external accessory. I added some new functionality to the app and some new artwork. When I submit the app to Apple, I get a warning that all apps submitted to the App Store need to support 64 bit as of February 1.
To make the accessory work, I use a library provided by the manufacturer, which is only compiled for 32 bit. I was able to use this library because I made my app 32 bit as well. As of February 1, however, I won't be able to submit any updates, because of the 64 bit requirement.
I suppose the only way is to request the manufacturer to provide me with a 64 bit version of his library, or is there any way around this to make my app 64 bit compatible?
It is not possible to compile a 64-bit application with a 32-bit library. You will need to obtain a 64-bit version of the library.
In order to solve the 3G (Ubuntu) memory issue (sometimes we do need more memory than 3G), I compiled my app under a 64bit environment to use more memory.
But, my 64bit app is much slower than the 32bit version.
32Bit version is built on a 32 bit machine;
64Bit version is build on a 64 bit machine;
both 32Bit and 64Bit versions run on the 64Bit machine in our loading test.
I googled, and some folks said, the unnecessary long type can make the 64bit slower than 32bit, because:
man g++:
-m64
Generate code for a 32-bit or 64-bit environment. The 32-bit environment
sets int, long and pointer to 32 bits and generates code that runs on any
i386 system. The 64-bit environment sets int to 32 bits and long and
pointer to 64 bits and generates code for AMD's x86-64 architecture. For
darwin only the -m64 option turns off the -fno-pic and -mdynamic-no-pic
options.
So I changed all my longs to ints, but still same result.
Please advise.
Peter
Edit:
About memory, both 32 and 64 versions use similar memory, about 1.5 ~
2.5 GB, and my machine has 9GB physical memory;
I profiled using OProfile, and for most of the functions, the 64bit version collects
more profiling samples than the 32bit version;
I cannot think of any
other bottlenecks, please advise.
My app is a server, and the loading test was done under a 100 client connections. The server does a lot of computation processing the audio data from the clients.
Profile your app. That will tell you where the slow code is.
For the question "why", no one will know the reason without details. You must analyze the profiled result and if there are any problem with the result, post it as a question here.
If your app does not need more than 4GB of RAM (1.5~2.5GB in your case), you should try x32. It's a new ABI that allows for 32-bit pointers in 64-bit environment.
On http://caml.inria.fr/download.en.html I can only find the version 3.11.0 for Windows 32. Is there a precompiled OCaml 3.12.0 for Windows 64?
To provide a tidbit of information that could also have been provided there (but wasn't), there are roughly three categories of supported targets for the OCaml compilers.
In the first category, common architectures, binaries are provided by INRIA: Windows 32-bit, Linux, Mac OS X.
Targets platforms in the second category are those for which they have one installation. INRIA OCaml developers can reproduce bugs specific to that platform if you report them, but none is using the platform as its main development platform, and it would be too much work for them to release binaries for all platforms in this category.
Target platforms in the third category are those they do not have immediate access to.
64-bit Windows is a second-tier platform.