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.
I am trying to do some embedded programming for an online course. The IDE I had to use does not have a Linux version, so I am planning to use the ARM DS-5. It says it can be used with eclipse but I cannot figure out how to get them to work. I have Ubuntu 14.04. I read somewhere that the ARM-DS-5 wouldn't work with anything newer than indigo but that was from 2012 and am not sure how accurate that is now. Any help would be great.
Depending on the use-case, you can pick one the three DS-5 variants.
Community Edition
Free to use.
Allows Linux library/app debug using GNU tools.
Comes in two flavors - Eclipse Plugin and Full Fledged IDE.
Professional Edition
30 days free evaluation.
Allows bare-metal (no OS) and Linux kernel and app debug.
Comes with ARM compiler, debugger along with GNU tools.
Comes with FVP, ARM's virtual hardware, allowing development without real hardware.
Ultimate edition
Everything in the Professional edition plus support for ARMv8, the ARM's architecture with 64-bit support.
You can visit here to see more detailed difference between various editions.
Note there is only one DS-5 IDE installer, which is available for download here. The variant is decided based on type of license chosen. So if you download DS-5 Ultimate for 30-day eval, it can converted to Community edition by changing the license at the end of eval period.
There is two options - SunStudio or gcc toolchain. What is the common practice to adhere when developing a driver -- make sure it builds with both compilers for 32-bit and 64-bit modes, or pick one compiler and stick to it?
Thanks.
There is no point building a 32 bit driver when you target Solaris 11.2 as this kernel is only released as 64 bit.
Both Solaris Studio and gcc can be used. The former is likely more popular for everything kernel related and you'll probably find more documentation about using it than gcc.
Until you can find someone who has used recent versions of the entire suite of tools available under both GCC with all its add-ons and Oracle's Studio toolset, you're not going to get a good answer. I'll say that I've yet to see an open-source tool that is as good as Oracle's Studio collect/analyzer tools at performance analysis of multithreaded large-scale applications, especially on Solaris. Most people who blindly post "GCC is better!" don't know the Oracle tools even exist.
Regarding device drivers, jlliagre's comment is quite relevant - it's quite possible to run into situations where a "native" compiler will work where a "foreign" one won't.
(Posting as an answer for emphasis)
I have just watched the bug report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6972329 so I want to ask... Is there a JDK upgraded version which handles the problem? Because if I develop an app with 32-bit JDK 6 will it work on 64-bit linux?
I have compiled my project with jdk 1.6.0_05 so I am not sure will it work for 32 or 64 bit linux ... won't it be the user.home as '?'
Thanks
The bug has absolutely nothing to do with the JDK used to compile Java code - Java bytecode is completely platform independant. The bug only occurs when you run a Java app on a 32bit JVM on a 64bit Linux, and even then it seems to depend on a specific (and possibly faulty) LDAP configuration.
Firstly, what is this called? Is this the system's "platform"? If I want to know if a system is 32-bit or 64-bit, do I ask what "platform" it is?
Next, is what I wrote below correct:
-A 64-bit processor can run a 64-bit operating system or a 32-bit operating system (with a loss of efficiency).
-A 32-bit processor can run a 32-bit operating system only.
If I want to know if a system is 32-bit or 64-bit, do I ask what "platform" it is?
"Platform" is an overloaded term that can mean a great many things. It can mean the CPU family: x86 platform, IA-64 platform, x86-64 platform, ARM platform, MIPS platform, SPARC platform, etc. It can mean the underlying operating system: Windows platform, Linux platform, Solaris platform, etc. It can mean a combination of these: Wintel platform (Windows + Intel). It can mean specific distributions: Debian platform, Slackware platform.
If you want to know if a system is 32-bit or 64-bit, ask if it's 32-bit or 64-bit. And make sure that you also check the CPU for compatibility for your purposes. ARM cores are 32-bit too, but you can't run Windows on them (at this time). SPARCs can be 64-bit, but you won't be running your copy of Microsoft Office on it, I'd wager.
A 64-bit processor can run a 64-bit operating system or a 32-bit operating system (with a loss of efficiency).
This depends very much on the processor. Intel's IA-64 chips can't run 32-bit operating systems because they don't really have 32-bit instructions (if memory serves). About the only way you could run a 32-bit OS on one is if you emulated a 32-bit CPU of some sort. This would suck performance-wise.
On the other hand the x86-64 chips can run 64-bit OSes or 32-bit OSes with no loss of performance at all for the latter (when compared to a pure x86, I mean). I'm running a 32-bit version of Ubuntu, for example, on an x86-64 chip without difficulties. Of course the 64-bit system will run faster than the 32-bit if the underlying software was written to take advantage of the expanded capabilities! (You'd be surprised how little it matters for most day-to-day tasks, though.)
A 32-bit processor can run a 32-bit operating system only.
Again, it all depends on the processor. An x86 (not x86-64) can run 32-bit OSes, but can also run 16-bit OSes right down to plain old MS-DOS. On the other hand, ARMs tend to be 32-bit only. (There are some ARM cores that have 16-bit instructions, but most do not, again if memory serves.)
I'd strike the part about "with a loss of efficiency". 64 bit processors can run 32 bit OS's just fine; with exception to Itanium which require special OS builds.
Efficiency has nothing at all to do with it.
To give a partial answer: 32-bit or 64-bit is part of the architecture. I guess it is part of the platform too, but you're more likely to make an expert think of the 32/64-bit distinction by talking about architecture.
Honestly, if you want to know whether a system is 32-bit or 64-bit, just ask, "32-bit or 64-bit?"
Assuming we mean on bare metal, the second statement is true. The verity of the first depends on the processor architectures. IA-64 processors cannot run IA-32 operating systems without emulation, whereas EM64T processors can.
If you want to know if a system is 32-bit or 64-bit, you could ask what "bitness" it is.
Whether the statements about 64-bit and 32-bit processors running 64-bit and 32-bit operating systems are true depends entirely on which processors and operating systems you are talking about. You won't have much success running Windows XP on an 64-bit Alpha or SPARC processor.