I want to use some methods in the ole32 and gdi32 libraries under Linux, but these two libraries do not exist under Linux, so are there alternatives when using under Linux?
I am using CGO
Use the following way to quote
#cgo LDFLAGS: -lws2_32 -lgdi32 -lole32
No, there are no in-place alternatives for these libraries on Linux as they are part of proprietary Win32 API and facilities they provide are specific to Windows only.
To make your application build on Windows and Linux you will need to abstract parts of application that use Windows specific libraries and implement them again for Linux using relevant replacement libraries (likely with different interface). Typically this is done so that programming interface - such as functions, methods, types, etc. towards your application are same but the underlying implementation is platform specific (using e.g. gdi32 on Windows and your favorite GUI framework on Linux). To achieve this Go provides Build Constraints mechanism that tells compiler to pull-in/ignore only certain files from codebase on each platform.
Go's own os package is good example of doing this.
If your application is heavily dependent on Windows ecosystem and porting does not make sense, perhaps building Windows native binary and running it in Wine emulation layer on Linux might be cost-efficient option.
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 am curious about mechanism of Linux compatibility layer of FreeBSD and got some info below.
https://en.wikipedia.org/wiki/FreeBSD#Compatibility_layers_with_other_operating_systems
https://unix.stackexchange.com/questions/172038/what-allows-bsd-to-run-linux-binaries-but-not-vice-versa
The key difference between two OSes is difference of system calls.
And, I know Linux app and BSD app depend on different standard dynamic libraries (linux-gate.so.1 for example).
Is there anything else in the implementation?
The approach to being able to run Linux apps in FreeBSD is multi-faceted.
The parts of the strategy, as I understand it, are as follows:
Provide a system call layer that mimics as close as it can the Linux system call structure and semantics. In FreeBSD, this layer is called 'the linuxolator'
Install a set of vanilla pre-compiled Linux userland libraries. These libraries work because the linuxolator provides the right system calls that they depend on.
Install/provide/mount platform services that Linux userland libraries and apps expect. For example:
Mount a Linux-compatible procfs - linprocfs.
Install pre-compiled Linux apps and have them depend on these Linux userland libraries.
The Linux Apps call the Linux libraries which call the Linuxolator's Linux system calls which call the FreeBSD system calls.
Some functionality is available on Linux (udev, systemd, inotify(7), ...) but not on FreeBSD (and probably vice versa).
Some system calls have different flags. FreeBSD mmap(2) is not exactly the same as Linux mmap(2), etc...
Both are Unix systems, but the devil is in the details.
If you want to code in C an application for both OSes, try hard to follow POSIX.
The code is written in c/c++，may depend some libs in the compiling host;
and it should run in another host without libs depending problems. Both hosts are linux, may have different versions.
Do you have a good strategy?
Pure static linking on Linux is discouraged, it's only really possible if you use an alternative libc (such as dietlibc) which isn't an option with C++, my favoured approach is to build the application on the oldest version of Linux you have to support as the newer libc builds will have backwards compatibility.
This will only cover libc, other requirements, such as gtk, pangom, etc will have to be compiled directly into your binary.
Link the application statically, so that it depends on as few dynamically loaded libraries as possible. This is the general solution to this problem.
Other solutions include:
Ship the required libraries with the application, and override the system's LD_LIBRARY_PATH variable to make the included versions the preferred ones.
Write code to dynamically load the libraries using dlopen() and friends, and handle differences in library versions manually.
Most platforms have a well-defined ABI that covers C code, but ABIs that cover C++ functionality are not yet common.
A program written in c++ using just libc may not run on another platform.
if binary compatibility is an important issue consider using c.
Take all answers for this question into account (static linking, compiling on the oldest Linux, etc.) and then check your final binary by the Linux App Checker to show compatibility issues with other Linux distributions.
When writing an application using the GIO and GVFS libraries from the GNOME stack what platforms will my application be available for? Will it be possible to compile the application on Windows, Solaris or *BSD, for example? Are the GIO/GVFS and dependent libraries available as binary packages on those systems?
GIO is part of glib; it uses POSIX APIs so it should work on all *nix systems, and it does have some support for Windows. GVFS is a client-server system, includes *nix-only headers and doesn't seem like it supports Windows at all.
I would start with the glib binaries on http://www.gtk.org/download-windows.html and go from there.