Can someone clearly tell the difference between the terms "cross platform" and "multi platform"
Cross Platform is where the host development architecture is different than the target execution platform. In short, the target application will not execute on the host development system.
Multi Platform is where a different executable target can be built that will also execute on the host.
Example 1 - You can cross develop from 64 bit linux to 64 Bit Windows using Wine.
Example 2 - You can compile an application for 32 bit Linux using multilib that will execute on 64 bit Linux using the native Linux compiler and using the -m32 switch to build the 32 bit application.
Example 3 - You can target 32 bit Windows applications from Linux 64 if you install Wine32 in addition to Wine and generate both the targets from the same source base if you are using the right toolkits.
Related
I am getting the below error when I try to execute the below line of code in my project. I added a 64 bit JDK to my project properties . I am using Intellij as my IDE
System.loadibrary(smsjavaagentapi)
Fatal Error: Exception from System.loadibrary(smsjavaagentapi) java.lang.unsatisfiedLinkError smsjavaagentapi.dll: Can't load IA 32 bit .dll on an AMD 64-bit platform
I think the problem is that I am using a 64 bit JVM and I am trying to run a 32 bit .dll. I don't have an option to install 32 bit JDK on my machine and add it to my project properties nor I can port the .dll to 64 bit . Is there a work around for this?
There is a limitation at the OS level which prevents a 32-bit shared library being loaded by a 64 bit process, so your options are
modify the OS to allow this (not easy)
migrate the DLL to 64-bit by recompiling it.
install a 32-bit JVM (easier)
download a 32-bit JVM and unpack it without install it. (doesn't require any special permission)
You might find you can get a version of IntelliJ which ships with a 32-bit JVM, or install another program which installs a 32-bit JVM and use just the JVM.
I'm currently trying to connect MongoDB to a Windows QT C++ application and am following the tutorial here. While there Windows installation instructions are presented, to avoid having to install Visual Studio or other tools, I'm wondering if I can follow the package-manager or Linux instructions on the inbuilt Linux/ Ubuntu subsystem of Windows 10 and build the libraries in my Linux environment, later somehow accessing them from my Windows development environment.
I don't fully understand how compilation/ byte-code works in the Linux subsystem on Windows, so I haven't been able to piece together an answer for this myself based on my understanding of the various systems involved. Any explanation or assistance would be appreciated.
You can run a Windows executable from a WSL console window or a Linux executable from Windows command line / power shell. And capture the output, pipe between applications etc. But the application must run entirely on one platform; you cannot mix a Windows executable with Linux libraries or vice-versa.
I don't know how you will connect to MongoDB but, if it has a socket interface like MySql, you could create a bash script on WSL which runs your QT application to access the database, wherever it is.
But if you're using QT as a GUI you're going to struggle. People have been able to get a Linux desktop running on WSL by installing an X server on the Windows host but you might find that more trouble than it's worth.
I am working on the development of a Java application that loads native library files to perform some calculations. The application uses JNI to load the libraries. This application should work on Windows and Linux environments (on both 32-bit and 64-bit).
During the compilation process, we compile C code to library files (32-bit and 64-bit dlls for Windows, and 32-bit and 64-bit .so files for Linux environments). These .dlls and .so files are included in the distribution file, and are referenced when Java is called by using the -Djava.library.path parameter.
I am now testing the application on a few different machines. I am initially focused on 64-bit Windows environments. The strange thing that I have encountered is that on some 64-bit machines the application loads the correct .dll files successfully, but on some other machines it does not load the .dlls.
I thought that the problem might because of a difference in the processor type between the machines (ie. that the dlls were compiled for one processor type and other processors types cannot use them).
However, it works on one machine, and does not work on another machine that has the SAME processor:
It works on a HP laptop running Windows 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 5, GenuineIntel
It does not work on a Lenovo laptop running Window 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
My question is: apart from the bitness are .dlls machine/processor type specific in some other way? (I know that the .dll files have to match the bitness of the machine, and that the JVM must also match the bitness of the .dll files)
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit machine that is using a 64-bit JVM?
apart from the bitness are .dlls machine/processor type specific in some other way?
Very much so. Any compiled binary meant to run under an operating system is both processor and operating system specific, sometimes even down to specific versions of each.
Different processors - even in the same family, such as "x86" - can offer different instruction sets and capabilities. See https://en.wikipedia.org/wiki/X86_instruction_listings for the listing of different variations of just x86 instruction sets and capabilities. If a compiled binary uses a specific instruction, it won't run on a processor that doesn't implement that instruction. For example, if a binary is compiled to use SSE3 instructions, it won't run on processors that don't implement SSE3.
And it's not just limited to hardware, either. Operating system specifics matter, too, literally for starters because the operating system is what starts the running process. So the binary needs to work under the conditions and in the environment of the operating system that started it. A binary designed to work under an operating system will also need to make calls to that operating system to interact with data, devices, or other processes. Different operating systems provide these capabilities in vastly different ways, even to the point of different versions of the same basic operating system doing so in incompatible ways.
And binaries that aren't designed to run under an operating system have to provide very hardware-specific capabilities - ever notice how many device drivers any operating system has? And this excludes any shared object or DLL because by definition they are already designed to run under an operating system.
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit
machine that is using a 64-bit JVM?
It should be clear by now that the answer is "Not even close".
I'm attempting to build a Linux browser plugin using Firebreath that runs on 32bit and 64bit Linux.
In my X11/projectDef.cmake I have
target_link_libraries(${PROJECT_NAME}
${PLUGIN_INTERNAL_DEPS}
"${CMAKE_CURRENT_SOURCE_DIR}/lib/libOIS-1.4.0_32.so"
)
Currently I'm just manually changing that line switching 32 to 64 when I want to do a different build, so that's probably wrong. But my issue is that even when I build with the 32bit library and it compiles successfully, I get the following error when trying to load the plugin in Firefox:
$ firefox
LoadPlugin: failed to initialize shared library /home/daniel/.mozilla/plugins/npBoomstickJavaScriptJoystickSupport.so [libOIS-1.4.0.so: wrong ELF class: ELFCLASS64]
How do I set up my cmake to automatically include the correct library depending on the architecture? Is there a way to build both x86 and x86_64 simultaneously on the same machine? How do I get the plugin to load correctly or is there a way to further debug this problem?
As far as I know the only way to do a build for 32 bit on a 64 bit machine is to use cross compiling: http://www.vtk.org/Wiki/CMake_Cross_Compiling
I've never actually tried this, but inside CMake you can probably use the CMAKE_SIZEOF_VOID_P which will be 4 in 32 bit mode, 8 in 64 bit. You could add an if to your cmake script to set the correct binaries depending on the size of that.
we are thinking about buying and setting up a new PC to use as a nightly build PC. We are planning to install Visual C++ 2005/2008, SVN etc. However we need to compile our app:
for 32 and 64 bit
on 2 different linux distros
so we think we can setup a Windows Xp/7 and use VMWare to run linuxes.
But how to build for 32 and 64 build targets on the same Windows ? Should we rather install a 64bit windows from the beginning ?
Do you have any other suggestions/best practices for dedicated build computers ?
Thanks,
Paul
First, separate 2 logical parts: build system architecture and physical implementation.
For example, architecture may be based on hudson: One server runs hudson and hudson manages builds on any number of other servers (running any OS'es you may need).
Now it doesn't matter if you have multiple PCs running single OS or have everything virtualized or a mix of both.
For physical implementation, I would recommend complete virtualization: it has several pros while the list of cons is basically one item - performance penalty.
I'm not sure about 2005, but 2008 can compile for both x86 and x64 on a 32bit system.
Not sure what you planning on using to do the builds, but if you configure a x86 and x64 configuration in your project MSBuild works just fine.
msbuild /property:Platform=<platform target> <project or solution file>
I would be tempted to install 64-bit Windows, not necessarily so you can build 64-bit executables but because it'll allow you to use more RAM without jumping through unnecessary hoops. And being able to use more RAM means you can give the Linux build VMs more RAM, run them in parallel etc.
I personally would go with x64 so u can test... Plus it will obviously be faster