I am thinking about port some of my matlab (on windows) applications to linux, the application is integrated in matlab on Windows, it will call some external library routine (I mean DLL, not .mex files) thourgh matlab's calllib routine.
However due to the expensive license fee, I want to port this to Octave in Linux, I just want to make sure the Octave can handle the external binary libaries just as well as Matlab (My application seldom use matlab toolbox so the lack of certain toolboxes on Octave should not be a problem for me).
Last I checked, Octave did not implement the loadlibrary family of functions.
That doesn't mean you can't interface with this external library; you could always write a MEX/OCT wrapper function and call the library in your C/C++ code (I'm assuming this library has been ported to Linux in the first place!).
Generally, a DLL is incompatible to linux. Your application will not run on linux, neither with matlab nor with octave.
Related
My background is in Windows and I'm a Linux noob. Still trying to wrap my head around some basic concepts, and specifically the system libraries:
Windows has ntdll.dll which wraps system calls, and a CRT dll
which interface between the C syntax to the ntdll OS-exposed
services.
(for simplification I ignore the intermediate layer of
user32, kernel32, kernalbase etc. I also realize the CRT is several dlls, this is not the point).
It seems Unix/Linux has pretty much just libc, which wraps system calls and called directly from your application code.
Is this the right analogy? (ntdll + CRT) <===> libc ?
I realize that C & Unix evolved together, but am still surprised. Can it be that the C interface is hard-wired into the OS for Unix/Linux? In Windows non-C programs link against the underlying OS provided dlls. Is it possible that in Linux there is no OS/C-runtime border?
In general, most programs link against libc, even if they are written in another language. It provides the C standard library interface (like MSVCRT), POSIX features (the equivalent of certain parts of the Win32 subsystem), and wrappers around system calls. For example, Rust uses libc because it provides a portable environment to link against.
However, on Linux, you don't have to link against libc. Go chooses to make system calls directly, which means it can ship static binaries that have no runtime dependencies. This is possible because Linux guarantees a stable kernel ABI, but not all operating systems do this (e.g., macOS). So unless you have significant resources (like an entire programming language team), this isn't generally a smart move unless you're only working with a handful of syscalls.
I should point out that even Windows is intrinsically wired into the C language: it uses C strings (granted, usually wide C strings) for its system calls, and much of the kernel is written in C. Even if you were starting a kernel from scratch, you'd still need a general C interface, because virtually every programming language has a way to interact with C.
The Linux system calls are documented in syscalls(2) and are the foundation of user-land programs. The calling conventions are documented in the ABI specifications. The ELF executable format is documented, e.g. in elf(5).
Read also Advanced Linux Programming and about the Unix philosophy.
You can make system calls directly in assembler. The Linux Assembly HowTo explains that. You'll prefer to use the C interface, and for that reason the libc is preferable. In practice, the libc.so is the cornerstone of most Linux systems.
Play with ldd(1), pmap(1), strace(1), BusyBox
The GCC compiler enables useful language extensions, and mixing C and assembler code.
Some programming languages implementations are barely using C and could call system calls directly (look into SBCL or Go ...)
Both the Linux kernel and usual GNU libc (or musl-libc), and also the GCC compiler and the binutils are free software or open source, and you can study their source code.
Things become trickier with systemd and vdso(7).
See also http://linuxfromscratch.org/
Graphical applications are using some display server, often Xorg or Wayland. Read about X11. You would want to use GUI toolkits like GTK or Qt to code them.
since dlopen uses libdl.so , but i am working on standalone application which do not use OS support, so my idea is to implement dlopen directly using coding is there any
Loading shared libraries is intrinsically dependent on the operating
system's runtime loader and in turn on the operating system's executable file format and its process construction model. There is no OS-independent way to do it.
The GNU source code of dlopen is of course
freely available, but that does not make it independent of an operating system.
The maximum degree of OS independence you can achieve in C is obtained by
restricting yourself to software that you can write entirely with the
resources of the Standard C Library. The Standard C Library does not contain
dlopen or any equivalent functionality, because such functionality is
intrinsically OS-dependent.
As your question is tagged Linux, it is not quite clear why you would want your application
to be independent of OS support that is provided by Linux.
In MATLAB, I have a MEX file ending with .mexa64. That is, it is for Linux 64-bit.
Now, I wish to call the function in my Mac MATLAB, which requires .mexmaci64. How may I do the conversion? Is it possible?
It is impossible to do the conversion without recompilation.
Simply recompile the source code, e.g.,
mex sourceCode.c
It will automatically give you sourceCode.mexmaci64, if you are on OS X.
I am aware that there are (at least) two radically different kinds of shared-library files on Unix-type systems. One is the kind used on GNU/Linux systems and probably other systems as well (with the filename ending in ".so") and the other used in Mac OS X, and also possibly other systems as well (with the filename ending in ".dylib").
My question is this --- is there any type of test I could do from a shell-script that would easily detect which of these two paradigms the current OS uses for shared libraries?
I'm sure I could find some way to easily deal with this variance --- if only I knew of a simple test I could run from a shell-script that would tell me which type of shared library is used on the current system.
Well, I guess you need to check filetypes of executables on a target platform. You may use file for that (check its output for, say, /bin/ls ). ELF is a most widely used executable type on Linux, while Mach-O is "natively" used in MacOS X.
A note: technically there're other executable types on these systems, say a.out and PEF, and, you guess, those formats have their own dynamic libraries. Frankly speaking Linux has a pluggable support for executable formats and even Win32 .EXEs may be executed "quasi-natively" in Linux (of course, they need an implementation of Win32 API working above a given kernel API, WINE is a such implemetation).
Also if you need to create a dynamically loaded library, then you should use one of those portable build systems (to name a few: GNU autotools, CMake, QMake...). Thus you'll get not only ordinary DLL extension but also linker flags, portable methods of installation/uninstallation and so on...
I am looking to compile a .m file (program) from MATLAB to Linux. I have done it on Windows operating system using
mcc -mv FILENAME.m
I see on the MATLAB website that I can use GNU g++.
Does this work in a similar way to the MATLAB compiler by just writing one line of code in MATLAB or do I have to run it in the Linux terminal?
Also, does this compiler tend to have issues regarding getting the desired output?
What you want to do, is called crosscompiling. Here you want from a Windows computer cross compile a Matlab program to a native Linux executable. As of 2009, this was not possible and most likely isn't now either.
Perhaps you might try using Octave for Linux.
Download GNU Octave