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.
Related
Libraries built with Mingw-w64 require those dll:
libwinpthread-1.dll
libstdc++-6.dll
libgcc_s_seh-1.dll
I wonder what's up with that, what each dll does? Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Why mingw requires to always bring those dll with your exe?
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler. It's so bloated though, 9 gb for installation.
Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Newer versions of GCC (4.8+ if I'm correct) should support SEH on MinGW.
I wonder what's up with that, what each dll does?
They provide the runtime and standard library.
libwinpthread: PThreads implementation on Windows (Threading)
libstdc++: C++ Standard Library (C/C++ library functions etc.)
libgcc_s_seh: Exception handling (SEH)
Why mingw requires to always bring those dll with your exe?
Because your program uses them. If you write a program without threads, standard library and exception and any OS interaction you wont need them.
These DLL's bring everything you need to run your program. Btw. this is not a MinGW only thing, and happens on other systems / compilers too. Often you just don't note this because the OS already ships the libraries, eg. MSVC libraries are very likely on a Windows machine. Dynamic linking always requires some sort of library files, that are .dll on Windows and .so on Linux.
If you have it available on your system use ldd <your application> to see what libraries are dynamically linked.
You can install these MinGW libraries into the system libraries or somewhere where the OS can find it. This enables your programs to use it and you no longer have to ship it with every application (what avoids duplication).
On the other side another option is to static link them. Unlike dynamic linking, you don't need any DLL; on the downside is a increase of you applications size (as now the three libraries are baked into the exe now).
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler.
This depends on your situation. But probably my answer will give you some more insight.
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
I was using powervr sdk gles 2 libs in linux in gamekit/ogre for building an application. I get the error
"dlopen tries:libGL.so" after which application crashes.
I tried debugging using DDD etc but couldnt isolate much.
How do I fix this in linux(Ubuntu 10.10)?
Does linux refer to some default in built libs while running dlopen?
A library name like libGL.so is only used for linking at compile time. When run-time linking, you should be using the SONAME; something like libGL.so.1. If that library has any dependencies, they must also be available. Try running 'ldd /path/to/libGL.so.1' and see if there are any missing libraries. Also, make sure that you're pointing to the correct libGL; there could be a few versions on your system, each optimized for different graphics cards.
I have a little application running on Linux and want to port it to Windows. I found that with Cygwin i will be able to do it simple by linking the application with the cygwin1.dll library which make available a lot of the POSIX and other standard functions. I read the FAQ and the User Guide on the site of Cygwin but didn't find or didn't understand how can I link my source with this library.
My application uses GTK+ and I successfully compiled and link it on Windows with MinGW but I have to disable some of the functionality .Now that I find Cygwin I would like to link with it to make available again this functionality.
Generally you compile your source inside of Cygwin to produce the Windows binary. I'm pretty sure Cygwin will take care of linking to the proper dlls for you.
When you finally get the binary compiled, make sure that the cygwin1.dll is in the PATH specified by Windows.
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.