A question to Linux and Windows Users

Posted by
December 28th, 2011 1:54 pm

I’m currently in the process of producing a makefile to compile my (future) game. However, In my interest to target as many people as possible I would link to know the following:

  1. What OS are you using? (Windows / Linux – Include which version if you so desire but it is not necessary)
  2. Are you using 32Bit or 64Bit? (This is the biggy)
Also, If there are any veterans who read this, what platforms do you suggest? (32 + 64, 32-only, 64-only)

Tags: , , , , , , , , , ,

13 Responses to “A question to Linux and Windows Users”

  1. ScreamRawr says:

    I use Windows Ultimate 64bit. Also, if you make it for 32, then the 64 users will be able to use it as well. So that’s probably your best bet.

  2. SirNuke says:

    I personally use 64-bit Windows 7 and 64-bit Ubuntu 11.10.

    For Windows, I’d just push a 32-bit build (and corresponding DLLs). It’s highly unlikely you’ll run into any issues with 32-bit compatibility on 64-bit Windows.

    For Linux, most Linux desktop distros have pretty good 32-bit compatibility libraries, though potentially not installed out of the box. I would ship (or static link) with any non-standard libraries (so stuff outside the zlibs and whatnot), and just tell the user to install their 32-bit compatibility libraries. With 3rd party apps on Linux, you’ll have to wash your hands and put your faith in your user’s technical skills at some point, might as well save yourself some headaches and just make a 32-bit build. You may want to strongly consider shipping your source for Linux, even if it’s not under a open/free license.

    Also, I’m not sure what your environment looks like, but I’ve had good luck doing cross platform builds with Ubuntu’s MingW32 compiler, which is considerably easier to automate than Visual Studio or whatnot.

    • dijumx says:

      This is a big help since I’m using 64-bit 11.10 Ubuntu myself. I’m actually using Ubuntu’s Mingw64 compiler (which has support for both 32- and 64-bit), alongside the latest shipped version of gcc/g++.

      Also, a fairly big question about libraries; this is my first project with any libraries (and cross-compiling), so I’m a bit confused about which directories are searched for required libraries at runtime. Is the directory of the executable searched, followed by standard directories (e.g. /usr/lib)? Or is the the directory specified at compile time, followed by standard directories? Or something else entirely?

      • SirNuke says:

        The exact directories are configurable, but I believe at least /lib and /usr/lib are required by POSIX and fully builtin. Additional system-wide configuration exists in /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf (changes are reflected when ldconfig is run). That said, you almost certainly shouldn’t be messing with any of that unless you are doing so through the user’s package manager. In fact as a rule of thumb you shouldn’t try to ‘integrate’ your game with the rest of the system unless you are distributing it as a package (so deb or rpm or whatevah).

        A better option is to use the LD_LIBRARY_PATH environment variable. Similar to the PATH environment variable, it’s a colon separated list of directories of where to look for libraries. It’ll look something like “LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/game/lib /opt/game/exe”

        Structure wise, let’s say the root directory is /opt/game. Let’s say game data including executable in /opt/game/data, and libraries in /opt/game/libs. You’ll probably want a script, let’s say /opt/game/run.sh, that sets the LD_LIBRARY_PATH variable, changes the directory to /opt/game/data, and actually runs the executable. This run.sh script is tailored to the system and generated by your installer.

        Installers are typically self extracting tarballs. You’ll can either make the self-extraction just a tar (so no compression) and gzip the entire thing (which will retain the executable bit) or make the self-extraction gzip’d tarball (but the user will have to set the executable bit themself, this case is more common – personally I don’t think an executable bit is really a good security feature but there’s a lot of hangwringing on this subject). Make sure your installer prompts for directory, probably default to somewhere in /opt if they are root and their home directory otherwise.

        One problem with distributing libraries is they can create weird conflicts: say system library A expects version 1.1 of library B, but you’ve distributed version 1.0. With LD_LIBRARY_PATH it’ll load version 1.0 before 1.1.

        You can also static link with libraries (static libraries are basically archives with a bunch of object files in them, .a is the file extension on Linux). This is easier to distribution as it doesn’t need LD_LIBRARY_PATH or anything but introduces potential license problems (basically can’t do this with LGPL unless you distribute your game’s source), plus users can’t replace the library later – which will almost certainly cause problems years down the road, plus it’s a slight waste of resources as the system is loading multiple copies of the same library (which also slows down loading your game – probably not an issue for fairly small games though). I’m not sure whether this dodges library version conflicts.

        Another option is the dl library and run-time library loading. With this you basically select what file to load at run-time, and using function symbols you can retrieve pointers to various functions. Thanks to C++’s name mangling (or specifically the lack of standard way to mangle names) it only works for C libraries. libdl is UNIX library for this, I think there’s similar functionality on Windows though it’s not necessary. Not sure whether this dodges the library version conflicts either, I want to say they do though.

        The ‘official’ path is to generate packages (deb/rpm/etc again). While in this case you’ll be able to simply mark libraries as dependencies, but you’ll need to generate a different package for every distribution you want to support. These are a pain in the ass to generate in my opinion, even if you limit yourself to a few distros. I’m not going to get into the argument, but in my opinion package managers are top notch at what they do but completely unviable for 3rd party software.

        So yeah, have fun.

  3. Nightmare says:

    For publishing a game, you’re going to want it to be as multi-platform as possible (granted it works on those platforms stable)

  4. Mostly Mac OS X (64bit) and Linux (32bit).

  5. DiThi says:

    I compile everything statically from linux for windows 32, linux 32 and 64. As someone said, 32 bit binaries on 64 bit linux run very well but you may need some libraries you don’t have by default. 64 bit windows binary is a gimmick but on linux it may improve the chances to run.

  6. Kelly Thomas says:

    I have winXP 32-bit, win7 32-bit and win7 64-bit running at home.
    As others have said if you target 32 bit windows 64-bit users will still be able to run it.

  7. Raptor85 says:

    64 bit linux, i can run most 32 bit stuff but not all due to library versions (the 32 bit compatability libs tend to lag significantly behind the 64 bit native ones). I’d love to go back to a non-multilib 64 bit system but there’s just too much still being released as 32 bit only binaries :/

  8. Manuel777 says:

    I use 64-bit windows and 32-bit linux, but only because my seller recommended it, i preffer 32-bit apps because 64-bit can run it with no issues.

  9. Osgeld says:

    64 bit windows 32bit debian (based) linux

  10. Sakar says:

    Windows 7 64bit

    Targetting 32-bit is best since 64-bit users can still run it, and honestly unless you’re doing some huge AAA game/software there’s no real reason to use 64-bit for your application.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]