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.
Related
Now Game maker Studio Pro is legacy so don't have more updates. Google Play Store have a new requisite to compile the apk on 64 bits architecture, but on Game maker Studio Pro it seems to be only the x86 option. How could I Compile with 64 bits architecture on that legacy version?
1.4 is legacy and does not support 64-bit architecture so you'll need to get hacky with it if you want it to work. I would take a look at this Reddit thread: https://www.reddit.com/r/gamemaker/comments/am4gwg/will_game_maker_14_be_adding_in_64_bit/
A user said:
so technically, you could build your game as YYC with 1.4.9999 and then change the references in the project libyoyo to the 64 bit versions
Idk how accurate that is but it's worth a shot.
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.
I have been using XCode on a Mac to create a simple SDL 2.0 project in C++.
I need to send the binary of the project to a company that uses only Windows 7 and allow them to run it without having to fiddle around too much.
The project uses some libraries (https://www.libsdl.org/projects/SDL_ttf/) so I am unsure on how to deliver to them something that they can run without having to install stuff.
Ideally I would want to create a binary (targeting Windows 7) which includes the libraries.
Any suggestion on how to do this?
EDIT: I found articles like this suggesting to cross compile but I am still a bit lost on how to start doing this. Will it work? Can it work on both the 32 bit and 64 bits Windows versions?
http://qt-project.org/downloads . I downloaded the openGL since many say this set standard is better. but now i got requirement from my prof that I need to provide something that can work on windows 32/64. Is there any way that i do not have to install Qt for windows 32 and produce an application that can be run on windows 32?
what I am saying is that I only installed Qt for win64 but now I want something can work on win32 platform. so I suppose one way is to install Qt for win32 and create a new project. But I want to ask whether I can maybe do some configuration and produce something that can work on win32 using the installed Qt on win64 on my com
thanks!
For Windows Vista and up, there's no reason not to use the ANGLE implementation of OpenGL that's bundled with Qt. "many say tis set standard is better" - this is false unless you can guarantee that your customers have a decent OpenGL-supporting graphics card driver installed on their machine. I'd suggest forgetting about system OpenGL, and use ANGLE implementations.
It's trivial to compile your project for both 32 and 64 bit Qt, if you really need the 64 bit address space. For many applications, there's no reason at all to provide a 64 bit version.
No, you can't do it directly.
The only way to launch 64-bit applications on 32-bit Windows is to use emulators and virtual machines, for instance VMWare. But it reduces the application performance.
Can it cause any problem if I use 32 bit library on a 64 bit system?
What could be the incompatibilities?
I know this question is too vague. An example :
I tried to setup FreeGlut 32bit library with VS2010 on windows 7 64bit. There were a lot of issues at first.So, I was looking for 64bit of FreeGLUT, thinking 32bit FreeGlut might conflict with 64 bit windows. But later on I managed to run my 32bit FreeGlut with my 64bit windows without any problem.
Question is, if there are any thing in the program, that we should look into while using those libraries which doesn't match with the system. (32bit library on 64 bit OS)
64 bit Windows is fully capable of running 32 bit applications. In fact, the default configuration for Visual C++ is to build an x86 application regardless of the operating system it is running on.
There are some gotchas you have to be aware of when running a 32bit app on 64bit Windows. For instance, there's registry redirection (to avoid it you pass KEY_WOW64_64KEY to e.g. RegOpenKeyEx). There's filesystem redirection, too. These are important things to have in mind when you are reading system configuration values, for example.
Also, be aware that you can't mix 32 and 64 bitness in the same process. Your 32bit app can't use 64bit DLLs or static libraries.
Visual studio can compile for 32 bit or 64 bit based on the project setting.
Probably, Question you mean to ask is about Linking 32-bit library to 64-bit program
The answer is:
You can't directly link to 32bit code inside of a 64bit program.
The only option is to compile a 32bit (standalone) program that can run on your 64bit platform (using ia32), and then use inter-process communication to communicate to it from your 64bit program.
It's not about the operating system- Windows doesn't care if your code is 32bit or 64bit. It matters that your process is the same bitness as all libraries it cares to load- and they must all be the same bitness.
You might be interested in this link explaining common compiler errors when porting to 64-bit. It might help you solve your problem.
To try to answer your question more directly, there are things that might make 32 bit libraries break in a 64 bit environment, but that's too much information to share in a SO answer.
This link is the MSDN index related to development for 64 bit systems and might interest you as well.
Your question could be about how to develop specifically code that will run natively on 64-bit versus 32-bit hardware. There is info on that here. In particular you would have to follow the instructions here to enable 64-bit build tools.
If you are building 64-bit binaries, you will need to link with 64-bit libraries. Note that 32-bit binaries should run just fine on 64-bit Windows, so you may not need to go to this trouble.