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.
Related
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.
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.
I want to write an shared library for Linux and Windows. My code must cross-compile on that operating systems. What is the best way to achieve this ? (compilers to be used are GCC on Linux and mingw on windows)
I should confess I do not even own a Mac, I have done Windows and Linux programming. Here I hope to learn something about Mac OS X by relating it to Linux if possible. And hopefully to be able to compile a Mac shared library without purchasing a Mac.
Note: There is absolutely no GUI, so Cocoa should not be required right? Also imagine I use C or c++0x, and POSIX for now.
What are the differences between Mac OS X shared library and Linux?
What is required to be able to run Linux .so files on Mac? Do I need a Mac-native replacement for ld-linux.so, and linux-gate.so or some other crt related object files?
Is there any cross platform gcc for Mac on Windows or Linux? (again no GUI)
Even though you don't need Cocoa/Objective-C, you still need to link against Mac OS X libraries (like libSystem, which is like libc on Linux). The file format is totally different (ELF vs. Mach-O) so there is no way to make a Linux library or tool work on a Mac without recompilation.
If you stick to POSIX/SUS APIs you can easily write things so they compile on both Linux and Mac without changes as long as you don't try any platform-specific things like reading Linux /proc files.
There doesn't seem to exist any cross-compiler for Linux-to-Mac development and I can't imagine anyone trying to do this: you'd be chasing a moving target without any real benefit.
The solution as always with these type of questions: buy a used MacMini on eBay or similar auction platform. They're cheap and will suffice.
I distribute a statically linked binary version of my application on linux. However, on systems with the 2.4 kernel, I get a segfault on startup, and the message: "FATAL: kernel too old."
How can I easily get a version up and running with a 2.4 kernel? Some of the libraries I need aren't even available on old linux distributions circa 2003. Is there an apt-get install or something that will allow me to easily target older kernels?
The easiest way is to simply install VirtualBox (or something similar, e.g. VMWare),Install CentOS 3 or any suitable old distro with a 2.4 kernel and build/test your app on that.
Since you're getting a "kernel too old", chances are you're relying on some features not present in 2.4 kernels so you'll have to trace down and rework that.
The error might simply be caused by linking statically to glibc, you could try linking to glibc dynamically and all your other libs statically, though to be backwards compatible you'd have to build your app on an old glibv system. Using the lsb tools to build could help too
For my use case, I can't statically link my supporting libraries. Also, current Linux distributions seem to make this difficult to accomplish for certain situations. But I needed my application binaries to run on 10-year old Linux systems.
I also didn't want to limit myself to an ancient 10-year old C/C++ compiler. I also found that the hardware I needed to use prevented me from installing a 10 year old Linux distribution for some reason.
So, I did this:
Installed docker.
Within a docker instance, install a 10-year old Linux system (I used Debian's Lenny distribution). This has the added advantage of making this build system available to any other machine that can run docker.
Within the docker instance, build the current GNU compilers (8.3.0 when I did this).
This gave me a modern compiler that compiled binaries that would run on very old Linux systems. I did this for both 32-bit and 64-bit processors.
From there, I created a series of scripts that allowed me to use the docker-contained cross-compiler to build all my supporting libraries. I made sure to set the rpath to my compiled binaries to a path relative to my binaries (using -Wl,-rpath,$ORIGIN/../lib), and a built a script to retrieve any supporting libraries from the compiler, using g++ -print-search-dirs to get the paths, ldd to get the supporting libraries I needed from my binaries, and some aggressive bash scripting to find the supporting libraries existing within the search-dirs from g++, dropping these libs into the rpath I set up.
From there, I package my binary accordingly, with all supporting libs.
Yeah, this is somewhat painful, but it results in a fully functioning binary capable of working on ridiculously old linux systems without having to install different Linux distributions on multiple virtual machines.
I tried creating a proper cross-compiler (native to the current Linux distribution hosting my docker images), but found it too difficult to work with, even with the best tools I could find to help me. Compiling the compiler within a docker image took far less of my time, and worked rather smoothly.