I want to build 64bit libraries for some of my C++ components. Is it required to compile/link the libraries in OS running on physical machine directly? Or can i use a OS running as virtual machine in ESX server to build the libraries? Would i need to take care of anything if i am building in a virtual machine? Please advice
I was interested in 32/64bit for linux.
Thanks in advance!
If the guest OS is 64-bit and you have a 64-bit compiler, there is not reason why you can't compile and run a 64-bit library/application in your virtualised OS.
Depending on the compiler (what are you using?) you might even just need to pass the right options to it and it will compile it wherever you want - even on a 32-bit machine.
This is a bit platform-specific. For example: on Windows I build the 64-bit binaries on a 32-bit machine (I have the 64-bit compiler installed with VS) and make sure that the correct redistributable pack is available on the target.
Related
Is it possible to make this library as 32bit? By default, this builds as 64bit.
How can i include this library in my 32bit application?
There's ways to cross-compile libraries, but it's usually easier to build from a 32 bit system if you don't know how. You can debootstrap a 32 bit userspace on your own system and use chroot to access it.
https://jblevins.org/log/ubuntu-chroot
It certainly is possible. Actually, one of gRPC's continuous tests is testing that the 32bit build works well.
We are using this 32bit dockerfile to build:
https://github.com/grpc/grpc/blob/5059fd195753d0c18e51efa930aebd7e0461ed51/tools/dockerfile/test/cxx_jessie_x86/Dockerfile
You can also crosscompile as others are mentioning above. You're not mentioning if you are building on linux, windows or macos, so I assumed you're on linux but building a 32bit grpc is possible on windows and macos too (and perhaps easier than on linux).
How do I know if the program I am writing in C++ will run properly in a 32-bit OS or not?
(without manually testing in one)
I am using Visual Studio and compiling in a 64-bit machine. Will that stop the program from working in other machines?
And what about the processor and Windows version? Will the binary be compatible with most Windows versions and processors, if the program just does a few simple things such as web requests and calculations, with a simple user interface?
My program doesn't have to be 64-bit. I would just like to create one binary that runs in most computers, like those I download every day on the Internet. How could I do that?
If you are building your code specifically for 64-bit Windows, you can't expect the binary to work on 32-bit Windows. That will require a separate build.
An executable compiled and linked for 64-bit will typically also require 64-bit libraries.
Use tools like the Dependency Walker to find out, if a given executable is refering to 32- or 64-bit libraries.
In Visual Studio, the "target platform" decides which CPU architecture you are targeting. It is perfectly feasible to create 64-bit executables on a 32-bit system, but you can't actually run them on such a machine.
You can do what's called cross-compiling i.e compiling on one machine for another. How to compile a 32-bit binary on a 64-bit linux machine with gcc/cmake This is what you're after if I read you correctly. There should be a Windows equivalent.
I am developing a cross-platform application and I need to determine whether machine B will be able to run the application that is compiled on machine A.
I am using Qt and I already understand that I need to either package the Qt libraries with the application or statically link against Qt itself.
I also understand that something compiled on Windows can't run on Linux.
However, there are still some other vectors that I'm not sure to what extent they matter. Here is the summary of my current understanding:
Affects Portability
Operating System (Windows, Mac, Linux)
Availability of third party libraries (Qt, static vs dynamic linking, etc)
May Affect Portability
Flavor of Linux (Ubuntu, Red Hat, Fedora)
Architecture (32 or 64-bit)
Version of Operating System (Windows 7 vs Windows XP, Rhel5 vs Rhel6)
Instruction type (i386, x64)
Of the May Affect Portability items, which ones actually do? Are there any that I am missing?
All. At least potentially.
If two different machines have no binary compatibility (e.g.
they run on different architectures, or interface to
incompatible systems), then it will be impossible to create
a single binary that will run on both. (Or... does running
a Windows program under Wine on Linux count?)
Otherwise, it depends. You mention third party libraries: if
they're dynamically loaded, they have to be there, but there's
always static linking, and there may be ways of deploying with
the dynamic library, so that it will be there.
The 32 bit vs. 64 bit is a difference in architectures: a 32 bit
program will not run in a 64 bit environment and vice versa.
But most modern systems will make both environments available
if they are on a 64 bit machine.
Issues like the flavor and version of the OS are more complex.
If you use any functions recently added to the OS, of course,
you won't be able to run on machines with an OS from before they
were added. Otherwise: the main reason why the low level system
libraries are dynamically loaded is to support forwards and
backwards compatibility; I've heard that it doesn't always work,
but I suspect that any problems involve some of the rarer
functions. (There are limits to this. Modern Windows programs
will not run under Windows95, and vice versa.)
There is also an issue as to whether various optional
packages are installed. Qt requires X Windows under Linux or
Solaris; I've worked on a lot of Linux and Solaris boxes where
it wasn't installed (and where there wasn't even a display
device).
And there is the issue whether it will run acceptably. It may
run on a smaller, older machine than the one on which you tested
it, but it could end up paging like crazy, to the point where it
becomes unusable.
If you compile an application on a 64-bit processor, it wouldn't by default run on a 32-bit processor. However, you can pass options to the compiler to have it compile code to run on a 32-bit processor. For example, if you're using GCC on a 64-bit machine, if you pass -m32, it will compile 32-bit code. 32-bit code by default can run on a 64-bit machine.
Sources
https://stackoverflow.com/a/3501880/193973
Different flavors of Linux or versions of operating systems may have different system libraries. For example, the GetModuleFileNameEx function is only available in Windows XP and up. As long as you watch what functions you use though, it shouldn't be too much of a problem.
The x64 architecture is backwards compatible with x86 ("32-bit"), so programs compiled for the x86 will run on x64 machines, but not vice versa. Note that there are other, less common architectures too, such as the ARM and PowerPC.
I can immediately think of three things that interfere with portability. But if your code is in a file format understood by both systems, an instruction set understood by both systems, and only makes system calls understood by both systems, then your code should probably run on both systems.
Executable File format
Windows understands PE, COFF, COM, PEF, .NET, and others
Linux by default ELF, OUT, and others
MaxOSX uses Mach-O
Linux has extensions to run the Windows/Mac formats too (Wine, Mono...)
Instruction set
Each processor is a little different, but
There is usually a "lowest common denominator" which can be targetted
Sometimes compilers will write code to do a function twice
one with the LCD set, one with a "faster" instruction set
and the code will pick the right one at runtime.
x64 can run 64bit and 32bit, but not 16bit.
x86 can run 32bit and 16bit, but no 64bit.
Operating System calls
Each OS usually has different calls
This can be avoided by using a dynamic library, instead of direct OS calls
Such as... the C runtime library.
Or the CLR for .Net.
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.
Is there any way I can cross-compile C/C++ code for Windows (XP, Vista, Win7), ideally in 64-bit as well as 32-bit (for Vista and Win7), from a Solaris or OpenSolaris setup? My codebase is already cross-platform, I would like to cross-compile it (generate windows DLLs and EXEs) from Solaris or Linux as part of an automated process.
I would like to use the GCC suite, and would rather not need to use the Cygwin DLLs, if possible.
If it is possible, which tools would I need in my Solaris environment? How would I go about compiling/linking an entire project?
If this is not possible in Solaris, how should I proceed from Linux, considering I would like 32- and 64-bit binaries for all of the versions of Windows I have mentioned?
Thanks in advance for any help!
I'm not sure if you want cross-compilation (creation of Windows EXE files on the the Solaris box) or cross-platform (code that compile on Solaris or Windows). The latter is easier, and to do it you should start by installing the MinGW version of the GCC compiler on your Windows box.
howto: Creating a cross Win32 and Win64 compiler
There is no 64-bit cross-compiler for Windows, you have to compile it using MSVC compiler :(
Er, why not just automate your build process by performing a remote build process? It's what we do - we have CruiseControl.NET on a Windows box which performs remote builds on Linux and Solaris via sshexec. I'm sure it would be possible the other way round.