I want to compile a customized Apache module for OHS on Solaris 64bit SPARC machine. It is a Apache C code. But what I have is only Windows machine and Linux VMs. Can this achieved using Oracle developer studio IDE. Or is there any other way? Please help
You can use QEMU and run a SPARC virtual machine under emulation:
Status
The table below gives the status of the SPARC machines available in
QEMU and is correct as of the latest release:
Machine Status
sun4m Complete, supported
sun4u Beta, supported
sun4v Incomplete, unsupported
niagara Complete, supported
Pay particular attention to the exact architecture you need to compile for. You should be able to run Oracle Developer Studio on the emulated system. You may have to use an older SPARC architecture to generate binaries runnable on your target systems. For example, you might want to use something like -xarch=sparcv9.
Note that the emulated system will be S-L-O-W. Large compiles can take hours or even days. You should probably develop your Solaris-specific code on an x86 VM, and only do the final SPARC compile on the emulated system. Just be aware that you can get away with strict aliasing and alignment violations on x86 systems that will throw a SIGBUS on SPARC systems.
Related
I have a working debian package that I'd like to backport to the current version of Raspberry Pi OS 64 bit (not 32-bit Raspbian).
Confusingly, while Debian itself seems to be robust about enabling cross-builds in their own package, there seems to be much less official documentation about how raspberry Pi OS (64 bit) packages are built¹.
Since I'm relatively certain this should be possible, I ask:
How to take a debian .dsc / debian rules, and build, on an x86_64, a 64 bit Raspberry Pi OS 64-bit compatible image
without using QEMU to actually build the image on arm64, without access to an actual RPi,
using an existing debian package that is known to work on sid on aarch64, and should be backportable,
making sure it's actually built against the correct set of Raspbian dependencies.
I'm guess this is a rather standard thing, I just don't know how to do it. I'm happy with using containers and similar technology, as I can easily integrate that with CI.
I do not plan to use an Arm64 VM, as the software in question takes about an hour to build and test, on an x86_64 server, natively.
¹I've talked to plugwash of Raspbian fame, and as earlier versions of this question showed: there's significant confusion about the heredity of Raspbian OS 64 bit: It's not Raspbian nor based on it. But people including Wikipedia and the RPi Foundation themselves conflate Raspberry Pi OS and Raspbian ("Raspberry Pi OS, formerly Raspbian"), which is 32 bit only.
RaspberryPi documentation here has explained how to build the x64 kernel from the source. What you want is in a way exactly like that.
Notice this line on the Kernel building page:
sudo apt install crossbuild-essential-arm64
This command on your Linux host machine installs a compiler that runs on an AMD64 machine but produces a binary that runs on an ARM machine.
And this line tells the compiler to actually build the source for that architecture:
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs
Image modules dtbs are specific to your project. they may differ.
As for your Debian package, there is no way that you can transform an AMD64 package into an ARM one. Your package for the RaspberryPi if doesn't exist in an official or some third-party repository, must be built from the source.
Find the source code of your package and build it very similarly to RaspberryOS.
If your Package has dependencies it gets a little more complicated. First, install the dependency on your RaspberryPi. Then you should set up a sysroot on your host machine which is basically a mirror image of the preinstalled packages on RaspberryPi. Then for compiling your package you should give the sysroot address to cross compiler so that it can find dependencies.
There is another way too, you can put the source code of your package on your RaspberryPi and build it locally which can take a very long time based on the source code. Just to have a sense, Qt source code without WebEngine module took 48h for me. But Qt is big.
In conclusion, if your package binary is not on any repository you must compile it from the source.
Cross-compilation of different projects and executables are very similar to each other. To have a clear understanding of the process it can be beneficial to look for some other projects that were ported to RaspberryPi OS. Things like Qt, TagLib for android, and ...
First, I would take a look here:
https://github.com/Truelite/qt5custom for inspiration. I checked and those scritps work. However, you might have problems going completely „qemuless”; e.g. in case of QT some libraries needed to be added to host machine sysroot and qemu was simply the easiest way to add them properly: it seems to me that multiarch Debian has some deficiencies in the field of cross-compilation and the simplest way to overcome them is to pretend it’s the native one.
I am currently writing an OS based on ARMv8 processor. I want to find an emulator that acts like the processor so I can see my OS working or not and to check my work.
I am on windows 10. are there any emulators recommended ?
I searched SO but no answer. thanks.
Looks like QEMU version 2.1+ is what you want
the latest version of upstream QEMU (2.1) now includes full ARMv8 system emulation support. This means that users can use upstream QEMU to run a full 64-bit ARMv8-A kernel and filesystem, such as a 64-bit Ubuntu cloud image. This was no small endeavour as it involved emulating a completely new instruction set, exception model, CPU implementation, and more. The implementation was verified with a custom instruction verification tool (RISU) and was heavily reviewed upstream by an engaged and incredibly supportive upstream QEMU community.
source
I need to test my C code for 32- and 64-bit versions of Windows (XP and 7) and Linux. But I have got access only to their 64-bit installations.
Question: Is it possible to use some boot-time settings or other hacks to run/emulate these OSes in 32-bit mode? If not, is there any other way to test the portability of my C code?
Note: The C code in question is not a full-fledged application but rather a .dll/.so file.
Neither Linux nor Windows 64Bit can run as 32Bit OS. Also, while you can run 32Bit executables on the 64Bit OS, it is not quite the same as running the same under a 32Bit OS. But it might work as a quick screening test. Besides, you certainly want that to work as well, right?
Your choices are full multi-boot setup, using VMs (might hide/expose bugs), being content with the emulation layer or running the other OS's on different hardware.
BTW: If you have Windows 64Bit, the license allows you to run 32Bit instead and vice versa. Anyway, you might want to check different language versions as well...
I have created an executable (.exe) of a perl script on a 64-bit linux kernel. It executes correctly in this environment.
When the executable is run in 64-bit Windows 7, the following error message is displayed:
The version of this file is not compatible with the version of Windows
you're running. Check your computer's system information to see
whether you need x86 (32-bit) or x64 (64-bit) version of the program,
and then contact the software publisher.
Given that the source and destination OS's were both 64-bit, I'm not sure that the architecture of the build is the issue. Are there any special considerations to make a compiled perl program execute properly in Windows? Thank you.
Executable files are not compatible across platforms. They will run on the original platform only unless they are explicitly cross-compiled to a different target. That's actually the reason we use interpreted languages. What you want to do is not possible because the Windows and Linux APIs, libraries, and well just about everything are completely different.
This is why you need to download a different version of a program for linux/windows/mac.
How compatible is code written under Solaris with Open Solaris ? I would be interested specifically in some kernel modules .
I think it is hard to quantify software compatibility, but I'd say code written for Solaris is quite forward compatible with OpenSolaris kernel. OpenSolaris source code evolves into what will be Solaris 11, and Sun's commitment to backwards compatibility is quite a fact.
Kernel modules written for Solaris should function in OpenSolaris following a simple recompile providing you are using the exposed kernel APIs that are compatible between the releases that you are using in Solaris and OpenSolaris.
There is a huge amount of work in Sun to ensure that programs written using publicly exposed interfaces are compatible. There is a listed 'Exposure/Stability' entry at the bottom of manual pages for most APIs that state in defined terms how someone can use it.
Kernel modules in particular will be very compatible between Solaris and OpenSolaris. OpenSolaris (via Project Indiana) is evolving the user-space components more heavily, including the installer and packages.
This is with regard to core OS daemons only and not kernel modules, but I've had success compiling OpenSolaris components from source and using the resulting binaries on commercial Solaris just fine. It's obviously easier with a Makefile but I did one manually.
I tried this with a small handful of binaries that I needed to add debugging output to and compiled them directly on the commercial Solaris system using gcc without issue. As mentioned earlier YMMV based on what app/module it is.