I'm working on my first Mac OS X app. My project was set-up with XCode defaults and I haven't touched any Build Settings. When building for Mac 64-bit, the app runs fine. However, when building for Mac 32-bit, I get a seemingly arbitrary error that says:
Semantic issue: Synthesized property 'myProperty' must either be named the same as a compatible ivar or must explicitly name an ivar.
What kind of things can I check for?
It sounds like you have found the error but I think I can answer your question just in case someone else later finds it.
Apple has made a lot of changes in the 64 bit Objective-C runtime which they couldn't do before since it would break binary compatibility. One of the things that is different is that in the 32 bit runtime synthesized properties have to be backed by instance variables. On the 64-bit runtime synthesized properties sill needs that but they are created automatically for you. By default the name of the instance variable should be the same as the name of the property.
So in case you need to support 32 bit then make sure that you create instance variables for all your properties. If you only support 64 bit then you can still do that so that your code can be built for both 32 bit and 64 bit at the same time but you don't have to.
You can set the NS_BUILD_32_LIKE_64 preprocessor macro in Xcode for the the 32bit build target. This will save you the trouble of maintaining separate code for 32bit and 64bit versions.
Related
I use a 64-bit OS to develop a JavaFX application and use Maven to build my application with javafx-maven-plugin to generate an installation package. The resulting package contains only a 64-bit application. So, is there a way to create a multiarch installator or create a pair of x86 / x64 installators in one pass?
UPD
Could you provide an example of a targeted build-system based on maven? Is it needed to use differents OS or just differents JRE on OS x64? In last case how to build the pair of installers per one run? How to automatically add a suffix to application name to noting the architecture? Is it needed to use e.g. Jenkins, or it can be done with maven alone? Is there a some "classic" configuration of the targeted build-system? And more, is there some drawbacks to use 32-bit application on 64-bit OS? From my tests follows that 32-bit app (for my case) is slower on 32-bit OS than on 64-bit OS. But 32-bit and 64-bit application on 64-bit OS work equally.
this is indended, because the underlying installers contain that information. There is no future where this can be provided, this was a JDK-bug once, but closed as "wont fix". As the javafx-maven-plugin uses the official javapackager-tooling, all benefits/drawbacks of that tooling is valid here too. This is even in the official documentation: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236
You need a build-system per targeted architecture.
EDIT: regarding your updated question: you can only create windows-launchers/installers on windows-systems, you can only create linux-launchers/installers on linux-systems, and the same form mac. This means in order to get launchers/installers from the one project, you have to run the build on every platform, and two times each. One time you have to call it with 32bit JDK being installed, and the other time with 64bit JDK installed (might work on Windows to only have JAVA_HOME being set, as maven picks this up), it does not need any tool like Jenkins, but if you have it, just use it.
About the performance I can't say anything, this is out of scope and is bound to the JRE itself.
Disclaimer: I'm the maintainer of that maven-plugin.
I have two machines, one running Vista Ultimate 32, the other one running XP SP3. both machines have the same VS2008 version installed.
I built boost 1.50.0 on the first machine (vista), and subsequently libtorrent library, that relies on boost.
I saw in some libtorrent build instructions that the win version is specified within preprocessor, so I did what seemed to make sense at the moment:
#define _WIN32_WINNT=0x0600 // being that the current OS is Vista
The build went successfully, and I was able to run the application on that machine. However, when I tried to run it on the other one (XP), it failed with the message, something like:
Procedure entry point SetFileInformationByHandle could not be located in the dynamic link library KERNEL32.dll
Now, logically, I'm guessing that this has something to do with incompatible versions, and probably different windows headers are included when this variable exists with different values.
The requirement: I'd like to build this on Vista or 7, and still be able to run it on XPs.
The question: Do I need this directive at all, and if I do, what should be the value? What else should I specify, if I'm missing something?
Try to build your program on XP or set _WIN32_WINNT to 0x0501 (as in your comment). The kernel32.dll library is backward binary compatible according to this report, so you can build your program with old version of this library (5.0) and run it with a new one (6.0) without the need to recompile. Vice versa is not possible due to a bunch of added symbols (SetFileInformationByHandle is one of them).
I have a 32bit iMac that I am writing an iPhone app in Xcode with, and I was wondering if I saved my project to a flash drive and dropped it on my MacBookPro which is 64 bit and continued to code the iPhone project on my laptop in Xcode would this cause a problem? I don't see how it would since the target is not for either of those computers, but I thought I would ask since I would like to work on the project when I am not always around my iMac. Are there any gottcha's with doing this that I should look out for?
Thanks,
I00I
No, this works fine. The compilers take source and compile to a particular target architecture; this is specified by the "-arch" flag to GCC. The executable produced is independent of the architecture that produces it. A compiler is a machine that takes input and produces output. It just takes your source and produces the output for the architecture you specify, no matter what the architecture on which the compiler is running.
I'm building an application that takes advantage of Mac OS X 10.6-only technologies, but without giving up backwards compatibility to 10.5 Leopard.
The way I do this is by setting the 10.6 SDK as the base SDK, weak-linking all frameworks and setting the deployment target to 10.5 as described in:
http://developer.apple.com/mac/library/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
This works fine; before making a call that is Snow Leopard-only I need to check that the selector or indeed the class actually exist. Or I can just check the OS version before making the call.
The problem is that this is incredibly fragile. If I make a single call that is 10.6 only I blow Leopard-compatibility. So using even the normal code code completion feature can be dangerous.
My question: is there any way of checking which calls are not defined on 10.5 before doing a release build? Some kind of static analysis, or even just a trick (a target set the other SDK?) would do.
I obviously should test on a Leopard machine before releasing anything, but even so I can't possibly go through all paths of the program before every release.
Any advice would be appreciated.
Best regards,
Frank
You could change the target SDK to 10.5. The compiler will then output warning: definition for '-snowLeopardOnlyMethod:' not found messages.
I am compiling a DLL that uses ATL to house a com object and targeting X64. Everything seems to be fine but the DLL wont run on the 64 bit machine. I ran depends on it on the target machine and it seems to be dependant on the x86 versions of countless system libraries (kernel32 etc.). Anyone know what i am missing?
I am guessing you are running the x86 version of Dependency Walker, which when analyzing a 64 bit DLL will show that it depends upon several x86 system libraries. You need to download and run the x64 version of Dependency Walker to see what is really causing the problem with your DLL.
http://www.dependencywalker.com
Need more details to be able to help, What are the errors you are getting?
The name of a DLL does not indicate if it's 64 bit or not, in windows there are versions of most system dlls on both 32 & 64 bits and they are named the same but placed in different folders.
The results you got from depends are troubling. Are you sure your DLL is indeed 64 bit? If it is, and it is linked to 32 bit DLLs, it will never work. Go back to your dev env and change those dependencies. If your DLL happens to actually be 32 bit, look for the 64 bit one...
You don't specify how exactly the DLL won't run (does regsvr32 work? if so, what error does creating an instance return?). In case you can indeed register it and you're trying to use it from a 32 bit client, make sure you specify the activation bitness correctly (see CLSCTX_ACTIVATE_32_BIT_SERVER and CLSCTX_ACTIVATE_64_BIT_SERVER). If this is the case, the dependency thing was a red herring, of course.