I'm trying to work with a co-simulator that communicates with Simulink using UDP packets. The problem is that in my Matlab installation I can't find the necessary library (Simulink real-time).
I read carefully each Matlab components during the installation but on Linux that library isn't present, on windows instead there is.
The missing block is this one here. Is there an alternative for that block available also for linux or where can I find this library?
Thanks
Related
Our vendor provides DLL, which works on Windows. Is this possible to load custom xxx.dll file and use its functions in Linux using Go?
Like this: https://github.com/golang/go/wiki/WindowsDLLs
The short answer is "no": when you "load" a dynamic-linked library, it's not only actually loaded (as in read from the file) but linked into the address space of your running program — by the special means provided by the OS (on Linux-based systems, at least on x86/amd64 platforms that's an external process; on Windows, it's an in-kernel facility, AFAIK).
In other words, loading a dynamic-linked library involves quite a lot of complexity happening behind your back.
Another complication, is whether the DLL is "self-contained" in the sense it only contains "pure" functions — which only perform computations on their input data to provide their output data, — or they call out to the operating system to perform activities such as I/O on files.
The way operating systems provide ways to do these kinds of activities to the running processes are drastically different between Windows and Linux.
The last complication I can think of is dependency of this library on others.
If the library's code is written in C or C++, it quite likely depends on the C library used by the compiler which compiled the library (on Windows, it's typically that MSVCRxx.DLL thing). (A simple example is calling malloc() or printf() or something like this in a library's code.)
All this means that most of a DLL written on Windows for Windows depends both on Windows and the C or C++ standard library associated with the compiler used to build that library.
That's not to mention that Windows DLL uses PE (Portable Executable) format for its modules while GNU/Linux-based systems natively use the ELF format for its shared object files.
I'm afraid not because the windows DLLs do different kernel calls than Linux shared object, both has this fancy name for system library objects
But if you need to run a windows native app on linux I would recommend give Wine a try, I doubt it works properly, and a second worthy try is dosbox, once I doubt this works too
But there is a little hope if those DLLs are written in .net framework, you could wrap them up on a nice c# code and use mono on linux side, not sure if this enables you to import those DLLs to golang, but I don't think so either
In the and with that amount of tricks to have everything working you will get some performance issues, just saying
I have an (xxx.so) shared library file and its based on powerpc linux.
now i want to use it in our project but first we need to convert it to X86 or X64 shared library for pc linux.
anyone can help me about this? Is it possible?
You can't: a binary file resulting from compilation of a C/C++ program is compiled for a specific Instruction Set Architecture. Since the two platforms have different instructions sets, you cannot convert the library of an architecture to the other. You need therefore to recompile the library.
First I would say that if you are trying to use functions from a library on one linux to another then there is a very good chance the library is available (somewhere) for your target machine. The odds are that the source code should be available.
If the library is specific to tat version of Linux then you should not be using it for cross platform work.
That said in principle you can :
Run the powerpc version of linux on an x86 or x64 system using a VM.
Try the the decompile-recompile route already suggested to you.
Write your own equivalent library for the target.
See if anyone has written a binary translation application for this purpose.
But if the library you want to use is simply not available for the system you are targeting, then you quite simply should not be trying to use it. It's practically suicidal programming practice.
I have an application for the USB interface in QT (Embedded linux).
When Pendrive inserted kernel sends a signal for that and i want to recognize that signal and want my QT application to detect it.
I went through the unix signal handling tutorial of QT but i could not find any way of my problem.
I implemented the same thing as done in the tutorial but i did not find the way to detect the pendrive. It only kills the processes.
Please go through the following link.
QT Unix Signal Handling
I have also found using QdBus library of qt. I cross compiled it but gave me the errors of lidbus version.
Is there any other way to detect the external pendrive from the application ?
The kernel is broadcasting netlink information. You can,
write a custom QSocket() to get netlink information. See: Qt Projects thread
write socket code directly to get the netlink info
use an off the shelf toolkit like libusb, which will use netlink.
add a script to udev.conf or mdev.conf to write a file and use QFileSystemWatcher; possibly /etc/fstab as well. udev and mdev are the standard hotplug handlers and they have configuration files that allow you to run a script on an event. The underlying mechanism is again netlink.
Parsing netlink or using /etc/fstab maybe better if you want to automount the file system. If you choose the parsing route, you need to parse the name=value informationSearch for netlink, which is quite easy.
I got the solution i Have used the busybox facility of mkdev.conf. In which i have added the support for the USB pendrive detection and used the udev utility to make the bridge between the linux and Application signal handler.
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 am trying to port an Windows executable to Linux using wine. I am at a point where I can run the executables but it returns some error saying it can't load "npf" driver. Is there a way to also port winpcap on Linux? The application I was trying to port is depending on winpcap library.
Thanks
libpcap? It is the original version of pcap that was then made into winpcap...
winpcap depends on the custom Windows drivers to provide access to the raw streams, it's not possible to port that as-is to wine.
winpcap is essentially a set of a Windows driver and two DLL's, wich enables applications to send&receive raw network packets to&from the network cards, and originally was a tool to have the same features than tcdump in Uxix/Linux in WIndows.
So, maybe a solution a wrapper in Linux of the "libpcap(capture) and libnet(send)" libraries, providing a winpcap binary compatibility? Playonlinux guys can help?