We have a C++ / Objective C based app.
We use LLVM-GVC compiler to compile our code.
Currently we build 32-bit binaries and deploy them on our customer's machines.
We support SnowLeopard, Lion, Mountain Lion and Mavericks.
I'm aware that all these are 64 bit OS. They can run 32 bit binaries fine.
But i want to know, going forward , is it a better idea to deploy 64bit binaries of my app?
I can compile our code base and build 64 bit binaries, but i will have to link against 3rd party 64bit libraries etc.
I think its do-able.
My question is what are the advantages of deploying 64 bit binaries, provided that 32binaries still work on these OS's?
Also what bout Universal Binary? Do you guys think building a Universal Binary would be a better option? If yes, why?
I'd appreciate any thoughts/suggestions.
If your binaries are standalone apps, as in they're not plugins or dylibs for other programs, then there's nothing wrong with using 32-bit binaries. You're in good company; if you look at Google's Chrome browser, that also uses 32-bit binaries.
The advantage of 64-bit is that you can address more memory, if required and I think there are a few assembler instructions that are faster with 64-bit instructions, but overall, if it works for you, I don't believe it's an issue.
If you find yourself creating a dylib that must work with both 32 and 64 bit applications, that would be a reason for creating a Universal Binary, to save having to create one of each and work out which you need at runtime; with a Universal Binary OSX will take care of that for you.
Related
I noticed that deployed on windows Qt applications are always including the dlls they needed.
Why did they made it that way?
Why can't they do it like on linux? - You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5).
Wouldn't it be better to make it like Java/.Net, e.g. you install Java/.Net then you run/develop applications using only one instance of libraries(dlls).
I find it kinda "unconservating": I have 7 applications that use Qt5, and all of them have Qt5Core.dll, Qt5GUI.dll, etc. and every of them takes some space. Feels like I have 7 packs of Qt5 libraries... x_x
While on linux these same applications use only "one" Qt library.
I noticed that deployed on windows Qt applications are always including the dlls they needed.
This is called "local deployment".
Why did they made it that way?
I can think of a few reasons.
To avoid DLL Hell.
It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)
You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)
Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.
Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:
Other Qt apps on that PC that are built with MinGW cannot run.
Other Qt apps on that PC that are 64-bit cannot run.
Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)
Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.
I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.
That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.
I have access to a 64 bit OS X environment, but I'd like to dramatically reduce the process for releasing native library builds for x86 / x86_64 / armv6 Linux and 32 / 64 bit Windows.
How can I cross compile JNI code from OS X (and failing that, from 64 bit Ubuntu Linux)? Which compilers must I install (I'm using macports) and from where can I install the foreign JDK environments that I must include and link against? What special compiler / linker flags are needed?
I'm using the maven-native-plugin so I can easily change the compiler, linker and JDK_HOME for every target. I have one module (i.e. pom.xml) per target platform.
The project, for those interested in details, is netlib-java/native_ref.
I've found out that various Linux cross-compilers come with macports in the form of
arm-elf-gcc
i386-elf-gcc
x86_64-elf-gcc
i386-mingw32-gcc
with 64 bit Windows cross-compile on its way.
Unfortunately, for my purposes I also need a Fortran compiler, so I'm asking for more help on that now on the macports mailing lists
EDIT: the current state of fortran cross-compilers (and mingw in general) on OS X is woeful. Best advice at the moment is to run a Linux box in VirtualBox and cross-compile all the targets from there. Two builds, not optimal, but better than all native.
I have the feeling that this would involve major nitty-gritty-details-stuff, nevertheless I'd like to give it a try:
Actual question
What do I need to do to set up an cross-compiler environment that allows me to build package binaries for platforms other than MS Windows (I guess at the moment this would only be Mac OS's tgz binaries) on MS Windows? The accepted answer in this post suggested that this is possible.
Background
I have quite a few mac users in my university's beginners R course that don't really know their way around the system specifics of Mac OS and therefore would be overextended with setting up the necessary development tools it takes to compile from source on Mac OS. Therefore, I'd like to offer them a tgz binary, but I need to compile on Windows as there's no apple hardware available to me.
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.
I have a 32-bit Windows/Qt application using Postgres plugin. Recently, I've been intrigued to turn the app into a 64-bit app. So I checked the Qt docs for instructions, built Qt and its libraries into 64-bit successfully. Now the problem is Postgres does not provide libraries for 64-bit Windows! Obviously, the Qt Postgres plugin won't compile. I googled around a lot and didn't find any solutions, just a whole bunch of non-helpful discussion archive postings. So, is there a way for me to compile my app as true 64-bit while using Postgres in Windows?
ADDENUM
The problem isn't running Postgres as true 64-bit on Windows (which cannot be done) (I'm not managing the database, so I don't care even), but to compile my Qt app as 64-bit (which very much gains from being true 64-bit). But since it needs to access Postgres DB, I can't do it, Qt Postgres plugin will not compile and I won't have DB access.
So, should I just separate Postgres related stuff to a 32-bit DLL (can I use 32-bit dlls with 64-bit app even?), or even to a separate executable, or can I use some other framework for accessing it...?
Give me any, even dirty, solution to this problem and state the pros and cons it may have and what else it might affect or break.
I'm about to get Vista 64 on my work machine so I was looking this up as well.
Basically - No, Postrgresql will not compile in Windows 64bit (yet), though it has worked for years in *nix 64bit.
I found this link - from one of the maintainers of the Windows installer.