I have created a game for my Uni project, said game runs fine however I can't run it on the University computers that don't have SDL2 installed and getting SDL2 installed on them is not possible.
Is there a way to package the SDL2 files while compiling so that I can run it on any Ubuntu system?
The above comments are right. You should use the Linux tool 'chrpath' or the rpath flag with gcc in order to reference your own packaged SDL libraries in your game binary.
As a starting point, I advise you to take a look at the Makefile of the GPL game Rock Dodger CE on bitbucket. It does what you are looking for. It references SDL2 libraries with the -rpath compiler flag.
In addition, that game ships the SDL2 libraries for 3 Linux architectures (i686, Amd64, ARMv7l).
(Look at the download section for the 'multiarch' package for Linux.) You can use those compiled libraries if they fit your requirements and you don't want to rebuild everything yourself.
I agree with you on the fact that there is not (yet) a comprehensive documentation about how to create "universal" packages for SDL2 games on Linux. Or I haven't found it yet ;)
Building compatible binaries for many Linux distributions requires first to understand the 'Linux Standard Base 5.0'. The tool Linux App Checker (from LSB) is designed to help you to achieve maximum portability for your binaries.
From my experience, I think that CentOS 5 is by far the most appropriate 'Long Term Support' Linux distribution for building universal binaries.
Related
I am planning on harvesting my gaming HTPCs spare cycles for compiling my software using distcc, but I will need to set up a cross compiler. The problem is that Google is sadly lacking in relevant information.
I think Cygwin is the purest form of evil, but is the easiest way of doing what you want.
You will just have to install the correct version of gcc from the cygwin installer.
This website has the answer here
Is it possible to compile native GCC for ARM (host == target == ARM) using Code Sourcery G++?
If it is not possible, could I use crosstool-NG to build the cross-compile and then using this one for compiling the native ARM GCC?
Thank you,
Edit: as to why: I'm creating my own distro for beagleboard...
CodeSourcery provides prebuilt toolchains only for Linux/x86 and Windows (see "Host System Requirements" here). If you want a native ARM-hosted toolchain, you should be able to build one using a cross-compiler. If you want a prebuilt one, you can try some of the existing ARM distros such as Debian-arm, or Aboriginal Linux (it's made to be run in QEMU but you can probably extract the compiler from it and run natively).
Tiny C Compiler runs decently natively on the kindle 3.
Find it on the mobileread forums compiled for native use.
Code sourcery toolchain works for simple comilation via "arm-none-linux-gnueabi-gcc foo.c" IIRC with no effort. creating native arms. Crosstools-ng as well but neither natively AIUI.
I looked into http://buildroot.uclibc.org/downloads/manual/manual.html#_about_buildroot
for a more comprehensive solution.
There are some options in there for what you require IIRC using x-compile to make the compiler but Crosstools is the more robust chain I had trouble with codesourcery doing true static build. HTH
better off to use openembedded
I need to support Windows 98. The Qt documentation claims this is possible, but there are no instructions. The distributed binaries of Qt 4.6 don't run on Win98 and the majority of Qt applications I have sampled also don't. For several apps that do run on 98, I have asked authors how they did it, but the common answer is that it was accidental and they don't know what factors caused it.
In searching the forums for help, I found only guesses that turned out to be wrong. For example, one belief is that to compile for Win9x, you must build the tools and the apps on that platform. Yet, things I found to run were built on newer versions of Windows.
What is required to build the Qt dev tools and then applications for Win98?
How about cross-compiling from WinXP or Linux?
Are there specific components that can't be made to run on Win98?
Are there particular difficulties with dynamic or static linking for Win98 support?
Here is as far as I'm going to get on this:
You can target Windows 98 using MinGW or VC++ 6 SP5 from any Windows version. Cross-compiling from Linux is doable but not easy to set up.
Qt 4.4.3 was the last version officially tested on Win98. To run the distributed binaries on Win98, you need to install older versions of glu32.dll and opengl32.dll that are available from Microsoft. Due to an unresolved bug, Assistant will launch but can't load the help files. The alternate version in the bin directory, assistant_adp.exe, works fine. It seems the only other potential problem is that QtOpenGL may use features not available on older boxes.
Qt 4.5.3 appears to be still compatible except for WebKit, OpenGL, and Phonon. QtOpenGL expects OpenGL 1.5, which I don't know is even possible on older boxes. I didn't look into Phonon deeply enough to see exactly what the problems are. QtWebKit now requires Win2K or better. The distributed binaries work mostly OK. Assistant depends on QtWebKit, so will not launch, but assistant_adp.exe still works.
Qt 4.6.3 distributed binaries are now completely incompatible with Win98. It may be possible to get some things working with MinGW 4.4 and a lot of hacking.
Building Qt Creator requires Qt 4.6.0 and either MinGW 4.4 or VS 2008.
Wow...interesting mission.
So, basically - yes, there is windows 98 support for Qt. The problem is that there is one big IF. For example if you even try to set some different QTextCodec::codecForName, you'll have to provide 3rd party ttf for this purpose, because in most cases Win98 will not recognize it as valid. If you provide the exact error, while compiling it on win98 machine, I could help you.
"How about cross-compiling from WinXP or Linux?" - If you use ONLY Qt libraries everything goes fine. Otherwise in .pro file, you have to link these libs under win32 and unix conditions. So you could even forbid your code, to be compiled and executed in other systems...
"Are there specific components that can't be made to run on Win98?" - Of course. In .pro file you could include different libraries, for different operating systems.
"Are there particular difficulties with dynamic or static linking for Win98 support?" - As far as I know - there isn't.
//off - But it still strange, that someone want to write application for win98, today...
Reference this question about compiling. I don't understand how my program for Mac can use the right -arch, compile with those -arch flags, the -arch flags be for the system I am on (a ppc64 g5), and still produce the wrong object code.
Also, if I used a cross compiler and was on Linux, produced 10.5 code for mac, how would this be any different than what I described above?
Background is that I have tried to compile various apache modules. They compile with the -arch ppc, ppc64, etc. I get no errors and I get my mod_whatever.so. But, apache will always complain that some symbol isn't found. Apparently, it has to do with what the compiler produces, even though the file type says it is for ppc, ppc64, i386, x_64 (universal binary) and seems to match all the other .so mods I have.
I guess I don't understand how it could compile for my system with no problem and then say my system can't use it. Maybe I do not understand what a compiler is actually giving me.
EDIT: All error messages and the complete process can be seen here.
Thank you.
Looking at the other thread and elsewhere and without a G5 or OSX Server installation, I can only make a few comments and suggestions but perhaps they will help.
It's generally not a good idea to be modifying the o/s vendor's installed software. Installing a new Apache module is less problematic than, say, overwriting an existing library but you're still at the mercy of the vendor in that a Software Update could delete your modifications and, beyond that you have to figure out how the vendor's version was built in the first place. A common practice in the OS X world is to avoid this by making a completely separate installation of an open source product, like Apache, using, for instance, MacPorts. That has its cons, too: to achieve a high-level of independence, MacPorts will often download and build a lot of dependent packages for things which are already in OS X but there's no harm in that other than some extra build cycles and disk space.
That said, it should be possible to build and install apache modules to supplement those supplied by Apple. Apple does publish the changes it makes to open source products here; you can drill down in the various versions there to find the apache directory which contains the source, Makefile and applied patches. That might be of help.
Make sure that the mod_*.so you build are truly 64-bit and don't depend on any non-64 bit libraries. Use otool -L mod_*.so to see the dynamic libraries that each references and then use file on those libraries to ensure they all have ppc64 variants.
Make sure you are using up-to-date developer tools (Xcode 3.1.3 is current).
While the developer tool chain uses many open source components, Apple has enhanced many of them and there are big differences in OS X's ABIs, universal binary support, dynamic libraries, etc. The bottom line is that cross-compilation of OS X-targeted object code on Linux (or any other non-OS X platform) is neither supported nor practical.
I've found a company that provides GCC based toolchains for ARM, MIPS but I don't know in what are they different from the vanilla GCC, of course, they bring other software pieces such as Eclipse, but when looking only at GCC and Binutils, are they different or just the same?
One big difference between a pre-compiled toolchain (like those provided by Code Sourcery, MontaVista, Wind River, etc) and one built from source is convenience. Building a toolchain from scratch, especially for cross-compiling purposes, is tedious and can be a complete pain. Also, the newest versions of glibc (or uClibc), gcc, and binutils aren’t always compatible as they're developed independently. There are open source tools to make this process easier (like crosstool-NG), but having a proven toolchain that’s been optimized for a certain platform can save a lot of time and headaches. This is especially true at the beginning of a new project. It also helps to have technical support when things go screwy. Of course…you have to pay for it most of the time.
That being said, compiling your own toolchain will most likely save you money and can allow more flexibility down the road. MontaVista, as far as I know, doesn’t include support for older platforms in their newest toolchain releases. For example, if you bought MontaVista Pro 4.X and it included a toolchain with gcc 3.3.X, that’s the toolchain you’re most likely going to be stuck with for the life of your project. Upgrading to a toolchain with gcc 4.X most likely wouldn’t be an option.
Hope that helps.