Compiling 32bit and 64bit on the same Linux box?

edited June 2018 in General discussions

What is the proper way to do this? In the past I have installed the 64-bit version of GCC onto the box using apt-get. Then I install 32-bit versions using something like: apt-get install gcc:i386 or along those lines.

This does work, but I have made a mess of my dependencies in the past.

Wondering what a clean way would be and what others use.

This post indicates using -m32 on a 64bit GCC compiler to force 32-bit builds: and



  • It really depends on your linux distribution. The ones I'm currently using do not allow me to do that: they're 64bit only.
    You need more than just gcc, you also need the libraries we're using in both 64 and 32bit flavors, including libsndfile, opengl, etc...
    You need to look into how your distribution handles multiarch packages.

  • Ah what a shame what a shame....

    It appears that libsndfile1-dev is not ready for multi-arch support and therefore cannot install both 32bit and 64bit on a system at the same time.

    The other three libs can be.

    But get this: libsndfile1 DOES have multi-arch support. Work that one out :(

    I made a 64-bit VM with gcc and g++ multilib, and it works a treat compiling 32 bit and 64 bit versions.

    But.... I have to keep switching libraries with:

    sudo apt install libsndfile1-dev
    sudo apt install libsndfile1-dev:i386

  • edited June 2018

    And again, it all depends on your distribution. Given you're using apt install my guess is that you're using a Debian/Ubuntu & co one.
    My current machines are either under Solus or Void, both of which are either 64bit only or do not have any multiarch support. I keep an old elementary 32bit VM to separately compile linux32.

  • I did try to find a package search that would show which packages support multi-arch on what distros, but I haven't found anything yet.

    I can't see a way of telling what distros would support it for which libraries.

  • This page lists distros that support multi-arch:

    I'd have to download each and try them to find out I think.

  • On further thought, ubuntu is a fairly popular and accessible distro with good support. I wouldn't be keen to encourage a particular flavour of linux just to get the ability to compile both 32 and 64-bit on the same system.

    Especially when it is a simple matter of switching by using:

    sudo apt install libsndfile1-dev
    sudo apt install libsndfile1-dev:i386

    This will be fine I'm sure.

  • It's also likely people will only care about 64bit as well. 32bit has been on the way out for quite a while now. It's been years most games out there do not get released in 32bit versions anymore.

  • edited June 2018

    That would suggest if I purchased a game on, for example, steam and I was running Win7 32-bit, it could be a 50/50 chance that I would be able to run that game? Is that the general pattern these days for developers for so little performance improvement?

    You can still purchase windows 10 32-bit.

  • edited June 2018

    It's not about performances but about not having to maintain two separate releases (and possibly diverging code bases).
    64bit CPUs for home computing were introduced 15 years ago and the last 32bit desktop CPU were released about 10-12 years ago, ie. there aren't many people playing modern games on 32bit platforms anymore.
    If we look at the Steam hardware survey from last February, you can see there is no 32bit versions of OSX nor Linux that have been used by Steam users, at all.
    As for Windows, there are 0.22% of WinXP 32bit machines and an unknown part of the ~2% of Win7/Win10 users whose OS doesn't disclose its type.

    In the facts, when looking at AAA games released over the past 5 years, I know that none of my employers over that time span have released a single 32bit game anymore, only 64bit versions.

    So yes, it's nice to propose a 32bit version of linux when releasing a game, but it's going to be used by virtually no players at all.

  • edited June 2018

    So, apparently I stumbled upon the same issue regarding libsndfile when setting up my buildbot linux slave.

    What I did in the end was:

    • install the 32bit version
    • copy its lib files (.a/.so) from /usr/lib/i386-linux-gnu to a temp folder
    • install the 64bit version
    • copy the lib files from the temp folder back to /usr/lib/i386-linux-gnu

    And now you should be able to build both 32 and 64 bit on the same box. Sorry I didn't remember that sooner, I only did it a few months ago but I completely forgot about it (thanks to .bash_history I was able to spot what I did :smile:).

  • Ah nice. I assume I could do the same safely enough. I'll give it a try.

  • This works a treat. I've added it to the Linux setup tutorial:

  • edited July 2018

    For Linux systems I recommend to follow all the official guide. At the end of the settings, fill in the library via the terminal:

    open the terminal inside the "gmake" folder in "orx-1.9/code/build/linux/gmake".

    then run:

    make config = debug64

    then also:

    make config = profile64

    last command:

    make config = release64

    It works without problems (tested on Linux Mint 19 x64)

    Useful advice:

    include a small bash script that compiles the library automatically (both debug and release). Very useful to make the process more convenient.

    The wiki does not describe the "gmake" folder to compile from the terminal (is it wrong, maybe it is I who did not see it in a hurry?)

  • Hi @XenonLab and welcome here!

    I guess we could add build scripts (we also thought of integrating that to our current setup/init system, but we still need to give it more thoughts).
    As for the gmake folder in the wiki, it's definitely something that could be added. If you feel like adding it yourself, just tell me what your wiki username is and I'll grant you write access.

  • edited July 2018

    @iarwain Thank you! I do not have a wiki username, but I will do it tomorrow because I'm going to reread everything and apply small corrections and very useful additions. the project wiki does not have a registration method, if possible I would like to be added with the nickname "XenonLab" in case I await your instructions.

    the setup script seems useful, I have not tested it yet but I will do it soon.

    Some things I'm discovering for myself, I'm not a professional programmer, but I've been studying and experimenting with various languages/tools for over 2 decades. I have a good theoretical basis of C/C++, Python, Lua, Javascript. I would be happy to give my contribution because with little effort Orx can be improved a lot.

    I did not find the presentation section in the forum otherwise I wrote my biography. Thank you for your welcome.

Sign In or Register to comment.