Like Windows' API are in the kernel.dll,user32.dll,etc., are GNOME API stored in *.so files?
If so, where are they? Can I use them as a shared library in my program?
If not, what are they?
.so are "Shared Objects" as known as dynamic libraries, different from ".a" that are static libraries.
I think in windows system there are only .dll (dynamically linked libraries).
Gnome APIs, since gnome is only a desktop environment, which makes use of other softwares elements like Nautilus (its window manager) etc. have exectuables and libraries (i suppose mixed betwwen static and dynamic.
Moreover it will use other libraries like libpng or libjpeg for images, libalsa for sound etc. etc.
and GTK (gnome toolkit) for the GUI
Finally more of them probably are in /usr/lib /usr/share/lib /usr/X11/lib ... and similar paths
GNOME is only a Desktop Environment - it provides you with high functionalities to manage the desktop, on top of the Window Manager, that manages windows on top of X.org, and so on.
There isn't a (single and well defined) set of GNOME APIs: you use various libraries from various projects. In general, GNOME stuff use GTK+ as their graphical libraries, plus lots of other libs, some quite GNOME\GTK-specific, while some others are more general. You can have a look here for info [1]
On your system, you'll find their binaries in .so objects somewhere (e.g in /usr/lib, /usr/share/lib, and so on).
To use them in your program, you have to #include the corresponding headers, for example #include <gtk/gtk.h> to use the GTK libs (the headers aren't installed by default in many distros, for example in Debian and Ubuntu you have to download the lib{libraryname}-dev package with apt-get).
To compile, you have to tell the linker and the compiler where are the libraries you want to compile against. To do that, you can use pkg-config [2] to find the right gcc -L and -I switches for most libraries (or you can setup your IDE - or instruct your Makefile - to do that)
[1] http://developer.gnome.org/
[2] https://en.wikipedia.org/wiki/Pkg-config
Related
I'm working on a project, which targets both Windows and Linux (and possible in the future MacOS). It consists of some applications with several shared libraries. It is written in modern C++ and modern CMake. It also uses 3rd-party libraries like Qt, OpenCV, Boost, GraphicsMagick, samplerate, sndfile. Those dependencies are handled through Conan package manager. I'm building both on Linux (Ubuntu 18.04, GCC 8.1) and Windows (via WSL - also Ubuntu 18.04, MinGW-w64 8.1). I'm using fairly recent versions of 3rd-party libraries with custom built options (strictly speaking - different versions than available on Ubuntu's APT, e.g. Qt v5.11.3, or custom built of GraphicsMagick)
I'm using CPack. On Windows I'm building NSIS installer, but on Linux I would like to use DEB generator (may be other if needed). All of my targets (written apps and shared libs) have appropriate CMake's INSTALL configurations, so they are copied correctly into the generated installers (component based installation). The real problem comes with packaging of 3rd-party dependencies.
Problem
Strictly speaking, I have no idea, how to do it well using CMake+CPack+Conan, both on Linux and Windows. I've read a lot of articles and posts, but I'm stucked. I would like to have something, that automatically bundles into the installer all 3rd party libraries used by project with needed plugins and, what is the most important, with needed system/compiler libraries (libgomp, libstdc++ and so on).
Possible solution
To my surprise, on Windows, this task is fairly easy, because every DLL used by app (my libs, 3rd-party libs and system/compiler libs) needs to be located where executable is. I'm engaging Conan into this, by importing all used DLLs into bin directory. In the end, in most naive way of packaging, I will just copy the bin directory into the installer and it should work. But I'm not sure, if this approach is OK.
On Linux, things are more complicated. First, there is arleady a package manager. Unfortunately, libraries/compilers available there are too old for me (e.g. on APT there is only Qt 5.9.6 ) and are built using different compile options. So, the only way for me is to ship them with my software (like in Windows). There are also issues with searching for dynamic libraries by ld, RPATH handling and so on. At the moment, the only solution I see is to write something like 'launcher' for my app, which sets LD_LIBRARY_PATH before program starts. After that, in this case we can just copy bin or lib directory to the DEB installer and this should work. But still, I don't know if this is correct approach.
Other solutions
I've also looked into other solutions. One of them was BundleUtilities from CMake. It doesn't work for me. It has a lot of problems in recognizing, whether some library is system or local one. Especially in WSL, where it stucked in processing dependencies to USER32.dll, KERNEL32.dll. BundleUtilities in Windows worked for me only with MSYS, but in MSYS I've failed to compile some 3rd-party libraries (GraphicsMagicks via Conan) and that's the reason, why I'm using WSL.
Summary
I'm looking for good and verified method of packaging C++ projects with multiple apps, libs and shipped 3rd-party libs, both for Windows and Linux. How are you doing things like this? Are you just copying bin and/or lib dirs to the installers? How (in terms of CMake/CPack code) are you doing that? INSTALL(DIRECTORY ...), or similar? I'm not sure, but I think that this problem should be already solved in the industry. ;)
Thanks for all suggestions.
First, Conan is a package manager for development, not for distribution, that's why you didn't find an easy way to solve your problem. Second, most of discussions are made at Conan issue, including bugs and questions. There you will find a big community + Conan devs which are very helpful.
with needed system/compiler libraries
This is not part of Conan. Why you don't use static linkage for system libraries?
Talking about CPack, we have an open discussion about it usage with Conan: https://github.com/conan-io/conan/issues/5655
Please, join us.
I see few options for your case:
on package method, run self.copy and all dependencies from self.cpp_deps, which includes all libraries, so you can run Cpack
Use Conan deploy generator to deploy all artifacts, and using a hook you can run cpack or any other installer tool
Out friend SSE4 is writing a new blog post about Deployment + Conan, I think it can help you a lot. You can read a preview here.
Regards!
I have been reading up on cross platform development with OpenGL for games. We are looking at developing a game which will be available to Linux users too. I have however come across something I am not quite getting my head around.
How to create a portable linux executable? Specifically how to get the various different versions of OpenGL / Mesa3D to work in one (or more) executable file/s (we do not want to distribute the source).
Over on Linux Questions http://www.linuxquestions.org/questions/linux-software-2/hardware-acceleration-using-opengl-and-x11-876634/ someone goes in to detail on how Mesa3D / OpenGL work but what I am struggling to see is how I would go about using each distro's version of Mesa3D within my compiled executable (not even sure if it is possible).
From what I can tell I am required to dynamically link parts of the application together on each users machine, possibly through the use of an installer? If this is the case can we part compile the program and link at runtime for Mesa3D / OpenGL much like OpenGL's dll's can do on Windows?
Just link your executable dynamically against libGL.so and be done with it. The binary interface of that is common among all implementations of OpenGL.
From what I can tell I am required to dynamically link parts of the application together on each users machine, possibly through the use of an installer?
Not you do the linking and neither does a installer. The dynamic linking happens automatically when the executable is loaded. Dynamic linking is how DLLs get loaded in Windows and the *nix counterpart Shared Objects (.so) on *nix.
When building your program, you add the option -lGL to the linker command line and it will add a dynamic linkage entry to libGL.so to the exeutable. That you can then redistribute. When the program gets started on the target system, the dynamic linker will locate the libGL.so and load it.
Is there anyway to write dlls in linux?
Do I have to install windows to write dlls in linux? Right now one of my courses requires me to write a dll for this.
You should take a look into 'shared libraries'
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
Lots of folks are getting near the right answer but not providing it: gcc can generate win32 PE/COFF files without problem, and of course can always build as a cross compiler on any platform it can target. The binutils port targets windows .exe and .dll files natively, and there's a "dlltool" utility for handling the edge cases where Unix and Windows linkage metaphors are different.
Additionally, the "mingw32" project provides a set of link libraries and header files for building C applications against the win32 API. These likewise install just fine on any Unix.
Here's a site I turned up after a quick google with instructions for building the toolchain.
Not really. Building any kind of executable intended for OS "A" while using OS "B" is a process commonly known as cross-compilation. In this partciluar case, you would need a cross-compiler running on Linux, but targetting Windows. I don't know any vendor selling such a product.
Let's say I have an application which I compiled under cygwin, and I want to distribute that application without having the user to install cygwin. Would it be enough to package the executable and the cygwin DLL?
Things have changed. The Cygwin libraries are now under the Lesser GPL (v3), which makes it possible to bundle them with applications that fall under a wide range of licenses, from FOSS to proprietary.
What stands in the way is that the POSIX emulation in Cygwin takes things a little too far from the perspective of native Windows applications.
This is where my Cygnal project comes in. Cygnal stands for CYGwin Native Application Library: it is a drop-in compatible fork of Cygwin which changes, or in some cases simply re-configures, the behaviors of certain functionality in order to conform with native conventions of the Windows platform.
A basic "Hello, World" Cygwin program requires two libraries. A GCC run-time called cyggcc_s-1.dll and the Cygwin DLL cygwin1.dll. The Cygnal project provides a replacement for the latter. (A 32 bit build is available for download).
One glaring area of incompatibility between the Cygwin POSIX view of the world and Windows is path handling. The Cygwin view of the filesystem is through a fake / root directory, and its own internal "mount table" which provides spaces like /cygdrive, /proc and /dev. Cygnal does away with all that. Paths are Win32 paths. The current working directory behaves like the Windows current working directory. Drives are associated with current directories, and drive relative paths like D:foo.txt work under Cygnal. Under Cygnal, /dev and /proc are still available: they are accessed as the special prefixes dev:/ and proc:/. It is not permitted to chdir into these: that would not be native! Under Cygnal, if you chdir to D:\wherever then your current drive is the D drive, and the paths /foo or \foo refer to D:\foo. Cygwin's master POSIX root directory is gone.
Yet, with Cygnal, you can continue to use the POSIX functionality, making it possible to develop cross-platform programs that have less code that is switched based on platform, compared to maintaining a port using MinGW or Microsoft Visual C/C++.
For example: you can write a Win32 console application using VT100 codes and termios. The same code will run on Unixes. No need to use the Win32 console API on Windows and VT100/termios on a POSIX system.
Another example: for threading, you can just use POSIX threads. pthread_create to start a thread, pthread_mutex_lock to lock a mutex and so on. Your program doesn't need a portability abstraction for threads which translates to Win32 or POSIX; you just use the POSIX and that's it.
The uname function in Cygnal reports the sysname with a CYGNAL prefix rather than CYGWIN. By means of this, your program can tell that it's running on Cygnal rather than Cygwin (or any other POSIX platform). Thus you can make any necessary adjustments: for instance, if your program needs /dev/null, on Cygnal it can look for dev:/null instead.
Does your application actually need any Cygwin provided Posix emulation? If not, you can compile it with the -mno-cygwin flag and it won't depend on cygwin at all, but will be a native Windows application. Often, you only need a real shell (bash) to configure and build your application, but you don't actually need the Posix functionality of Cygwin.
Another alternative is MSYS + MinGW, which is a light-weight fork of Cygwin. This provides a compilation environment which produces native Windows apps by default.
A third option would be to use the MinGW compilers from Cygwin itself. They should be available via the normal Cygwin package manager. Then you would configure the project for a cross-compile using the MinGW compilers.
Normally, yes. Be sure to install the Cygwin DLL in a public location though (Windows\System32), this DLL behaves very badly when multiple versions of it are loaded on the same machine.
You could try to compile everything as static. That should allow you to run everything without the need of the the libs (since they are already in your binary).
But this will also mean that it might not work an all platforms if cygwin would need a different or newer dll.
I have a cross platform program that runs on Windows, Linux and Macintosh. My windows version has an Icon but I don't know how to make have one for my Linux build.
Is there a standard format for KDE, Gnome etc. or will I have to do something special for each one?
My app is in c++ and distributed as source so the end user will compile it with gcc.
If I can have the icon embedded directly inside my exe binary that would be the best.
For Gnome and Kde, you would probably want to include a desktop file with your app that defines how it will be launched. The specification can be found here. If you have an installer included with your app, you would probably want to have it generate this desktop file and put it in the right places to make menu entries and whatnot
If you are using one of the pre-baked F/OSS build systems, such as KDE's CMake support, it's really rather easy once you have a .desktop file:
install( FILES myapp.desktop DESTINATION ${XDG_APPS_INSTALL_DIR} )
kde4_add_app_icon(myapp_SRCS "${CMAKE_CURRENT_SOURCE_DIR}/hi*-app-myappname.png")
If you are rolling your own, consider using xdg-utils, which includes handy little scripts like xdg-desktop-menu (installs desktop menu items) and xdg-desktop-icon (installs icons to the desktop) for such things.
The .desktop standard was already pointed out in the first comment, though you can also just grab one that is already installed on your system and modify it from there. As for icons, PNGs and SVGs are geerally supported though PNGs tend to give the best results still.
KDE community with it's KDE 4 series started to use CMake as a build system. They developed a CMake macro that knows how to set an icon for your application regardles of the platform (windows (embedded in exe), mac (.app bundles), linux (.desktop files) etc.)
Maybe you can use it.