I have a pretty big piece of code written in C++ and integrated into MATLAB via mex functionality. It was originally written in a windows machine but now that I run it on the Linux machine, it gives wrong result.
Is anyone aware of any difference between how Linux and Windows handles OS. It usually involves
#omp pragma for
I couldn't post the code here. I would really appreciate some insights into what might be wrong .
Related
I am in a strange scenario, where I must use a work windows 8 desktop how ever I am writing code to be run on a real time Linux machine. I am writing code for a Real-time system, so will need to implement many non-windows headers like RTAI and such. Obviously I can not run these on windows 8, so was curious if anyone had any suggestions for compiling and testing without having to upload code to the RTOS based computer I am programming for each time I want to run a program. I unfortunately can't use a virtual machine and would like to avoid coding in the terminal in order to remotely code on the linux machine.
Any suggestions?
You can code in Windows or whatever OS you like, what system your programming computer uses has absolutely nothing to do with the target system.
The cross compiler you are using must obviously be for the intended target system. Same goes for debugger & program download tools. Your program must either run in a simulator or it must run on the real target. The latter is strongly recommended.
So all you have to do is to acquire the right software tools. Since these are almost always written for Windows, that should be easy.
I'd like to develop haskell code that will run on windows and interact with windows OS APIs, but I would like to do it on a linux machine. How do I accomplish this? I can compile on a windows machine and that works, but not on a linux machine. Haskell can use a LLVM backend, can't it? Can I use LLVM to accomplish this? Or work with MinGW somehow?
I tried many possibilities, including GHC on Wine (didn't work for me, despite many notices advertising that it works "out of the box").
For cross compilation, one problem lies in making GHC find your C libraries and DLLs (for windows). Template Haskell will also give you headaches (because it needs to load linux libraries but then compile for windows).
I never managed to get around those problems properly.
In the end, I opted for installing GHC on a Windows VM, and now I use a script to push stuff to a repo, connect to the windows machine via SSH, pull, clean, recompile and test, all executed from a linux CLI and giving me feedback about what's happening on windows.
EDIT: I'm not providing this answer in an attempt to discourage anyone from trying something smarter. I too am interested in real cross-compilation and, if someone has a good solution, I'm all ears. My alternative method always works, but it really is a pain, having to start a VM just for this. Furthermore, it implies using one VM per OS per architecture, which is quite heavy.
I know about several projects for cross compiling between linux and Windows.
The Wine project is great for running windows application inside Linux.
andLinux is a linux running inside Windows.
My question is, can we compile a complete linux OS with a Windows compiler (like mingw32, visual studio , ...) in order to get a linux system which is fully compatible with the Windows PE executable format ?
As wine demonstrates, the PE format isn't really the problem with compatibility.
PE only defines how the program is pieced together at load time. Under windows, RUNDLL interprets it, loads all the program sections to memory, loads all the supporting dlls to memory and patches up the function pointers so that there is a program sitting in memory ready to go. (See http://msdn.microsoft.com/en-us/library/ms809762.aspx for more details. Its a good read!)
There is little stopping you writing a kernel module to do all of this. With the details in the page linked above it may not be to hard and someone may already have done it.
The real issue is the fundamentals of the operating system. Even if linux could load a PE, there would be problems around the fundamental difference in file names (\ or /) as well as the permissions model which is different and the windows registry which doesn't exist under linux. That's before you get into the different windowing model for GUIs.
Therefore the task of getting a windows program to run under linux is less about the program loader and much more about emulating all of the windows DLLs under Linux. As i understand it, this is the main heart of wine.
I just a ran simple hello world program in my linux it worked perfectly.when i supposed to ran same file in the hand held device (running on the linux os)i got the error like Cannot execute binary file error.i am completely new to linux.
can anybody help me?
Just because the OS is the same does not mean an executable will run. The binary file is composed of machine instructions the processor can understand. Moving back and forth between processors with the compatible instruction sets will normally work fine, but if they are not compatible the CPU will not be able to understand the instructions.
Most Intel processors use a x86 ISA (instruction set architecture), that your mobile processor is likely not compatible with.
Just a heads up because I had this problem but the b4-bit application for 32-bit OS didnt work for me. If your in linux you probably need a gcc compiler on the backend of terminal that might not be installed. If you dont have this Linux doesnt seem to know how to read the file.
su <user-name>
Then command/file should be executed.
I really hope there is some help to get on this subject. Has anyone ever used lua in an application that needs to have both 32-bit and 64-bit support? We are currently transitioning to 64-bit but are having trouble with client compiled lua scripts that we can't recompile ourselves using the 64-bit version. So in effect we need to be able to load bytecode files compiled using 32-bit lua in a 64-bit application. When we try to do so we receive an error message:
virtual machine mismatch in test.bin.lua: size of size_t is 8 but read 4
Well of course this is a clear 64bit transitioning problem. The hard thing is just to figure out what to do about it without the ability to recompile the binaries.
Thanks
It's not hard to adapt lundump.c to read 32-bit bytecode files. I've posted a roadmap for this in the Lua mailing list. If you have problems, please send me email.
You could try LuaDec: "LuaDec is a decompiler for the Lua language." I don't know much about it, and the website states that it targets Lua 5.0.2. So, it may not work out of the box, but it's better than starting from scratch.