I have a Makefile which generate binary, the problem is CRC values of same binary which is generated on Cygwin and Linux environment are different. what would be the reason.
Environment: Cygwin 64 bit
Linux 64 bit
The CRC changes because the executable file's contents changed. There is many reasons why the contents might change, but the main reason for you is that windows uses the PE32+ (or PE32 if you are using 32 bit machine) format and linux uses ELF format (macos uses March-O). Their headers and stuff are different so their CRC will be different.
Sometimes binary built on 2 different machines with the same OS will be different too. The reason is that the library path is different, or a machine got clang 12 and another got clang 15.
Also the generated file is not a C binary, it is a executable. A binary is just machine code (and a bit of data for the const values), with no other information, so the OS will have no way to run it (it doesn't know the libs to dynamic link to, the entry position...).
Related
I did write a small program using Haskell in Windows. The program depends only on base, diagrams-lib and diagrams-rasterific. The generated standalone executable is huge (25633 KB).
I have read several similar questions (Small Haskell program compiled with GHC into huge binary), but all of them presume Linux is being used. I think that the problem is that everything used (or not) is statically linked into the executable. This includes (I guess) the libraries that in Linux are taken as granted and in Windows are not available.
Any help for reducing the size of the executable will be welcome.
OS: Windows 7 64 bits Pro,
Haskell Stack: lts-8.16
Doing 'sizeof(char *)' from in 'C' programs shows pointers to be 4 bytes long rather than 8 bytes long in 64-bit Windows using Cygwin64's MinGW compiler. I'm specifically using the compiler 'i686-w64-mingw32-gcc.exe', which is the only MinGW compiler that I've found so far in Cygwin64. I've read about the 'WOW64' system in Windows that emulates a 32-bit environment but doubt that this is connected to the issue. Everything I've read so far states that pointers from 64-bit MinGW compilers should be 8 bytes long. So I'm confused about this and of course wondering how I might therefore be able to compile programs that use 64-bit pointers with Cygwin64's MinGW.
There is no default cross compiler, but instead there
are 2 sets for 64 and 32 bit.
mingw64-x86_64-*
mingw64-i686-*
https://cygwin.com/ml/cygwin-announce/2017-01/msg00035.html
I've decided to simply use a different MinGW compiler that I've downloaded. After I'd isolated the specific Cygwin64 download-file that provides the MinGW compiler and then unpacked and searched it for its executables, I found that it only contains the one compiler mentioned above that is a 32-bit MinGW compiler. So being that I can't yet make helpful sense out of the reference kindly provided below this by matzeri to that webpage information, I'm considering the following as my best solution so far to this problem. I've found a NON-Cygwin 64-bit MinGW compiler that's available online and have installed it to use in addition to Cygwin's various compilers whenever I need to create true 64-bit executables. I downloaded it from the website 'https://sourceforge.net/projects/mingw-w64/', and it seems to work great with it producing 64-bit pointers! (WARNING: A more heavily-referenced 64-bit MinGW compiler named "Dev-Cpp 5.11 TDM-GCC 4.9.2 Orwell+Mingw" that I looked into before this one shows as containing a Trojan-Horse virus when scanned with the antivirus App ClamWin!)
I made a cross compiling toolchain for arm-gcc, configuring binutils, newlib, gcc and gdb for the arm-elf target. The problem I am having is, when I compile a program with arm-elf-gcc on my Mac, it generates a 32 bit executable with cannot be executed in the 64 bit environment.
What is the easiest way to circumvent this? I could place the 32 bit executables to an arm environment, but I am interested to know if I could execute the file in my Mac in any way?
--Added--
I should have done this before, but let me inform that the target of my program is a Beagleboard, and I was expecting that I would compile and generate the objects using arm-gcc on my Mac OS X and transfer the *.o to the Beagleboard to view output. Alas, it gives the same error on the Beagleboard as well when I do a ./hello.o.
Thanks,
Sayan
There are several issues preventing you from running your executable on a Mac.
1) Architecture. Your Mac is probably an x86/x86_64 machine (or PowerPC) but your binary is compiled for ARM architecture (which is the whole point of using a cross-compiler). These instruction sets are not compatible.
2) Your binary is linked as an ELF object file, whereas Macs use the Mach-O object file format. Your OS cannot load this executable format.
3) Your executable is linked against newlib (for some target which is probably not Mac OS) instead of the Mac OS libc. Your system calls are not correct for this platform.
If your program is a standard unix executable, you may be able to simply compile it with the standard system gcc and it will run. Otherwise, you can run it in an ARM emulator, though this may be pretty complicated to set up.
The fact that it's 32-bit is irrelevant - you can't execute ARM code on a Mac (unless you can find some kind of ARM emulator).
I initially thought that 64 bit instructions would not work on OS-X 10.5.
I wrote a little test program and compiled it with GCC -m64.
I used long long for my 64 bit integers.
The assembly instructions used look like they are 64 bit. eg. imultq and movq 8(%rbp),%rax.
I seems to work.
I am only using printf to display the 64 bit values using %lld.
Is this the expected behaviour?
Are there any gotcha's that would cause this to fail?
Am I allowed to ask multiple questions in a question?
Does this work on other OS's?
Just to make this completely clear, here is the situation for 32- and 64-bit executables on OS X:
Both 32- and 64-bit user space executables can be run on both 32- and 64-bit kernels in OS X 10.6, without emulation. On 10.4 and 10.5, both 32- and 64-bit executables can run on the 32-bit kernel. (This is not true on Windows)
The user space system libraries and frameworks are built 32/64-bit fat on 10.5 and 10.6. You can link against them normally, whether you're building for 32-bit, 64-bit, or both. A few libraries (basically the POSIX layer) are also built 32/64-bit fat on 10.4, but many of them are not.
On 10.6, the build tools produce 64-bit executables by default. On 10.5 and earlier, the default is 32-bit.
On 10.6, executables that are built fat will run the 64-bit side by default. On 10.5 and earlier, the 32-bit side is executed by default.
You can always manually specify which slice of a fat executable to use by using the arch command. eg. arch -arch i386 someCommandToRunThatIWantToRunIn32BitMode. For application bundles, you can either launch them from the command line, or there is a preference if you "get info" on the application.
OS X and Linux use the LP64 model for 64-bit executables. Pointers and long are 64 bits wide, int is still 32 bits, and long long is still 64 bits. (Windows uses the LLP64 model instead -- long is 32 bits wide in 64 bit Windows).
Mac OS X 10.5 supports 64-bit user-land applications pretty well. In fact, Xcode runs in 64-bit in 10.5 on a compatible architecture.
It's only the built-in applications (Finder, Safari, frameworks, daemons etc.) also have the 64-bit version in 10.6.
Meta: I don't like to see answers deleted. I guess this has been discussed somewhere.
Anyway, KennyTM and the other kind sole got me started and although one answer was deleted, I appreciated your efforts.
It looks like this is expected behaviour on the Mac, and it even seems to work on a 32-bit Linux as well (although I have not tested extensively)
Yep. GCC behaves different (at least in my limited observation) for 32 (-m32) and 64 (-m64) bit modes. In 32 bit, I was able to access variable arguments using an array. In 64 bit mode this just does not work.
I have learnt that you MUST access variable parameters using va_list as defined by stdarg.h because it works in both modes.
Now I have a command-line program that runs and passes all of my test cases in 32 bit and 64 bit modes on Mac OS-X.
The program implements a linked list garbage collector sweeping 16-byte aligned malloc-allocated objects from a global list as well as machine registers and the stack - actually, there are extra registers in 64 bit mode, so I still have a bit of work to do.
Objects are either a collection of 32 or 64 bit words which link together to form LISP/Scheme-like data structures.
In summary, it is a complex program that does a lot of messing with pointers and it works the same under 32 and 64 bit modes.
Asking multiple questions does not get you all the answers you might want.
It seems to work, as I wrote, on Linux.
Again, thank you for helping me with this.
Is it possible to run the COFF executable files on UNIX or the ELF executable files on Windows? And what would be the steps to be able to run either file type on Windows and UNIX. I'm just curious.
To answer your question properly, it is relevant to review what ELF, COFF, and PE are. These binary formats are essentially just containers that give directions to the operating system about how to execute the raw CPU instructions contained in the file. They are very much like audio/video containers like MKV, WMV, and OGG. Support for the executable format is either in the operating system or not. Microsoft Windows has consistently not given any support for COFF or ELF, until recently. With Windows 10, Microsoft has provided indirect support for ELF by building into the Windows kernel UserMode-Linux compatible system routines. A UserMode Linux kernel runs on top of the Windows kernel and runs all ELF binary formats almost as if it were running independent of MS Windows.
The alternative to using the UserMode-Linux (sub-kernel) being for Microsoft to rewrite the majority of the Linux API in a completely compatible format, their choice solves one other compatibility issue: The API. "A" stands for Application and "I" for Interface, however the API as an interface is mainly just a set of executable routines and environment assumptions. Access to the filesystem and most basic system routines is provided by the Windows kernel, while everything else is provided in the UserMode Linux kernel. This way not only can Windows run ELF formatted executables, but in can run the most popular ELF executables that are already made to run on the Linux API.
The reverse, the other half of the question, running PE (most Microsoft Windows executables) on Linux is possible as well. There are two runtime wrapping libraries that can run MSIL (virtual machine application) and Win32 (normal CPU application). Because the Linux kernel is extendable to recognize a certain byte format, then run an appropriate wrapper program, in effect the kernel supports PE and potentially more executable container formats. Therefore, Linux can run some PE programs either in the mono runtime (.NET/C# applications) or in the WINE runtime (Win32 C/C++).
To install the UserMode-Linux environment you can follow instructions provided on Microsoft's Development Network. To summarize:
Turn on Developer Mode: Settings | Update & Security | For Developers | Check the Developer Mode radio button
From the start menu, open “Turn Windows Features on or off”
Scroll down and check the “Windows Subsystem for Linux (Beta)” feature
Hit okay and reboot (required step)
Once rebooted, open a PowerShell/command prompt and run “Bash” and follow the simple prompts to accept Canonical’s license and kick-off the download of the Ubuntu image
After download has completed, you’ll be able to start “Bash on Ubuntu on Windows” from the Start menu
Be aware this method only works on Windows 10 and is still limited to text-mode console and a Win32 port of Xorg like vcXsrv for anything graphical. Cygwin or MSYS2 systems are not able to run ELF binaries, but make it possible to port and run the same applications that are normally ELF binaries on a Linux system.
To actually run executables and have them do useful stuff, you need to worry about the API, not just the executable file format. On a Linux machine with WINE installed, you can run Windows .EXE files from the command line and they do the same thing that they do on Windows.
The other way around is not really possible, however if you install CYGWIN on a Windows machine, and then rebuild the application from source with CYGWIN compilers, you will get an executable that runs on Windows and does the same thing that the Linux executable does on Linux. Lots of standard Linux tools are already ported and in the CYGWIN repository including stuff like X-Windows and GIMP.
http://lbw.sourceforge.net/ works better than line.
low was another project for doing the same thing, but that was the less working.
EDIT: http://atratus.org/ seems to do the same as well, without the need to have Interix/SFU.
COFF was originally introduced by UNIX (around System V or thereabouts) so yes, some UNIX probably still supports COFF format. It's been deprecated by Linux at least for a while, and presumably most other Unices have also deprecated or outright dropped support.
Windows ELF support is a bit more iffy - almost certainly not there without some deep trickery. You should be more specific about what you're trying to do here...