next »

[mcc]

Any other C++ developers here? I have a bit of a problem and I don't really know where to go for help.

I made this game. Because the game was made using SDL/OpenGL and I carefully controlled the libraries I used, I'm able to do all the development on my mac and just run the game through mingw to create a windows binary. In theory, also, it ought to be possible to just compile the game for Linux and it should run.

However, I'm running into trouble when I try to actually create a Linux binary. What I'd ideally like to do is set up a crosscompiler, like the mingw install I already have for compiling Windows, on my computer. But I have two basic problems.

First, I'm not even really sure what target I'm supposed to be hitting with this crosscompiler! My understanding is when you build/install gcc you have to specify a single "target" that the gcc you're building compiles for, and this includes some fairly specific things like a libc and such that you're linking against. But aren't there more than one libc in wide use today?

Is it actually possible to compile just for some kind of generic "i386-linux" target and create a binary that different linuxes can run? Will I have to create separate binaries for different distributions, or different versions of a same distribution? (I'm not too worried about package managers, in theory my program should just be able to run out of the directory you unzip it into).

Second, where exactly do I get OpenGL headers from? When I installed mingw it came with opengl headers. However, I did some abortive attempts awhile back to compile my program on a linux server I have access to, and if I understood things correctly (maybe I didn't) apparently there are no standard linux headers? What was claimed to me at the time was that linux opengl headers actually come along with your video card drivers, like you have to install the nvidia drivers and the headers come with it. But this seems to mean that if you're compiling on a headless server (i.e., no X, no video card) or compiling outside of Linux altogether, you can't install video card drivers and thus can't get the headers. Am I missing something?

Every time I look into it it seems the answer to "how do you distribute binaries on Linux?" is "distribute source". But I don't think I'm comfortable doing that at this time. Has anyone ever tried to make linux binaries, does anyone have any advice on how to proceed?

Thanks.

[increpare]

I'd be interested in hearing this as well. I have no trouble distributing source, but it would still be nice to know how to do straight binaries...

[minasss]

You could try installing mesa libraries on the server

p.s.I've seen the game...very nice idea!

[magnum_opus]

Is it actually possible to compile just for some kind of generic "i386-linux" target and create a binary that different linuxes can run? Will I have to create separate binaries for different distributions, or different versions of a same distribution? (I'm not too worried about package managers, in theory my program should just be able to run out of the directory you unzip it into).

just compile with the -static flag and it'll run on most linux distros just fine.
and really in general things will run okay if you use dynamic linking too as long as the user has all the dependencies in their load path, the problem is that no two distros ever have the exact same version and incompatibilities abound. But static binaries will run pretty much anywhere.

that said I have no idea about cross compiling, I just have a linux virtual machine that I use to compile things.

[nihilocrat]

If normal old compiling / static linking doesn't create a suitable executable, I would second the virtual machine idea.

[mcc]

Thanks all...

minasss, if I compile using Mesa and then I distribute the game, will it run on other people's machines using Mesa or will it use the local hardware acceleration?

The VM thing is actually a really good idea... unfortunately my options are sharply restricted on that front because my mac is PPC and can't run VMWare etc. Thinking about it though maybe I can get Linux to run under qemu... I will see how workable that turns out to be.

[henzenmann]

Thanks all...

minasss, if I compile using Mesa and then I distribute the game, will it run on other people's machines using Mesa or will it use the local hardware acceleration?

If you just link dynamically to libGL, it should use whatever is installed on the target system - either Mesa (which *has* hardware accelerated backends for some cards), or the proprietary implementation from Nvidia or ATI.

The VM thing is actually a really good idea... unfortunately my options are sharply restricted on that front because my mac is PPC and can't run VMWare etc. Thinking about it though maybe I can get Linux to run under qemu... I will see how workable that turns out to be.

Qemu is trivial to set up if you don't need tun/tap networking. I usually just set up port redirection for SSH or other ports i need.

Code:

qemu -redir tcp:2222::22 disk.img

I use a setup like that at work to run a script locally that logs into the Qemu system, runs a script on there that checks out some stuff from SVN, compiles it and then downloads the build to my local machine with scp.

[J.G. Martins]

Yeah, I can confirm being able to run Linux under qemu. We did that not long ago, also under Linux, so we could tinker a bit with the kernel and modules and stuff without breaking it all. We did get a pre-prepared image, but it seems pretty accessible! Good luck!

You might want to contact the guys from NAEV. They're distributing Linux binaries and it seems to be working out. Not sure what dependencies they're using though. Might be the static thing, as I don't remember having to install any dependencies

[mcc]

Updates:

• Mesa turned out not to want to compile without X libraries, so I tried compiling xorg from scratch on the aforementioned headless linux server. What I learned: Never try to compile xorg yourself . Abandoned the effort when a dependency of a dependency of a dependency turned out to refuse to compile without Python 2.5 (not 2.3!) being present. Meh
• Qemu was more successful, it was surprisingly easy to get running and I was able to get it to boot an Ubuntu x86 LiveCD, albeit v e r y s l o w l y. Two things my experience left me wondering:
  
  • There is a mac shell for Qemu called Q which I used. It was rather nice but it didn't seem to support save states, which as far as I'm aware Qemu itself does. Given the LONG startup times on my computer, this is a feature I probably need. Is anyone familiar with this "Q" program? Does anyone know whether there is a way to get Q to do save states? Could this have to do with that I am running 0.90/stable and not 0.91/head? (At least one person I spoke to on Freenode seemed to believe Q supports save states.)
    
  • Although Ubuntu booted, once I got it up it ran too slowly to actually accomplish anything in the GUI-- for example, I couldn't seem to bring down the GNOME applications menu. I'm tempted to blame this on the GUI rather than Qemu. Does anyone know of anything which is like the Ubuntu livecd, but which boots to a vterm/command line or something instead of by default launching X? In general is there a good source of Qemu-ready disk images somewhere?
    

I've also learned that if I can't get Qemu working I may be able to get access to a linux machine which is GUI-ready, but if Qemu turned out to be workable that sure would be neat.

Thanks all!

[magnum_opus]

well qemu will never be very fast because it's emulating instead of virtualizing.
RAM is also an issue, especially when dealing with livecds, Ubuntu installed is going to eat quite a bit of ram too. Also Ubuntu may be a poor choice because it doesn't come with gcc et-al installed so if your dream is just to boot up a live CD and compile you're SOL.

I'd try a smaller live cd like Puppy, Damn Small or GRML small (note grml is text based). though i'm not sure which of those have gcc installed by default.

EDIT: none of the three i listed have gcc installed by default, so I'd go with grml (note grml-medium or large might have gcc, but they'll take more ram as well), as I'm pretty sure it's vanilla debian.

[J.G. Martins]

There is some sort of acceleration layer in Qemu, but it's not enabled by default. It's called kqemu, so you might want to look into that. I had to compile some stuff to get it working, but good luck!