C4 Engine Drops Linux Support, Calls It "Frankenstein OS"

[Cyber Killer]

That is not a work around, it is the only correct and robust way to install multiple operating systems without dealing with virtual machines. Wubi was a toy for previewing Ubuntu so can later install it properly on eg another hard disk or free space on an existing disk.

Creating virtual machines is usually a pretty good and useful way to have multiple distros on hand to make builds, test them, etc. Though not in this case, cause VMs don't work good with 3d acceleration that is needed for game engines.

[blackiwid]

Are you nuts? How about installing arch? Ok its edge case. How about installing mint when installer accidentlally crashes? Whats so easy about it then? Ofc most of the time it does not happen. But when it did happen i had to learn and manually set up lvm + luks. Valuable experience for me but not for most people. On the contrary installing windows never gave me trouble so please dont preach crap sir.

So you need to mention a profi distro, if you are a user that just want to install his first linux or wants just a running linux and is not willing to dig deaper why in hell would such person choose arch linux? But you kind of said self that this is a dumb example.

I never installed mint but ubuntu, I think its 99% the same because mint is ubuntu with some other default packages and maybe 1-2 own ppa like things enabled by default, so I answer it for ubuntu. Ubuntus normal installer does not support lvm only the cli based debian-like installer does that. windows installer does not support lvm or anything like lvm, so why in hell do you need that if you are a user that is in fear of linux problems?

Its a bit like choosing a family car for doing a racing competition, maybe thats no good idea.

luks is even cracyer, why do you need that? lvm dont needs luks, something with encryption basic windows does also not allow to encrypt so how can you compare this tasks when its maybe somethimes difficult task under linux and impossible in windows?

And again next step you compare a linux distro installation with a windows installation. A windows installation is more or less like debian-minimal installation. nothing what you need is there, you can search 5 days in the internet after 1000 setup.exes full with viruses and some cds maybe too.

Most of that (cant boot) Problems are then vendor problems driver problems... something like that, thats no linux problem, but a problem that this companies suck, and should go bankrupt.

[nanonyme]

If it is the solution then clearly something is wrong. Thats now how modern systems should be worked around. Seriously...

That is not a work around, it is the only correct and robust way to install multiple operating systems without dealing with virtual machines. Wubi was a toy for previewing Ubuntu so can later install it properly on eg another hard disk or free space on an existing disk.

[Cyber Killer]

I vaguely remember trying this method about a year ago. I do not remember the exact reason, but I was unable to get it work reliably on different distributions. Then again, we have a fair amount of libraries, and those libraries have many dependencies themselves so it is likely that the error was on my part. I will once again revisit this in the near future.

There's also stuff like multimedia codecs, fonts, etc to keep in mind too. As for libs - having too many dependencies is your enemy. For desktop apps sticking with something like Qt solves most library problems, but if you already are far into development, then there's no point switching now.

On a related note, do you have any experience with the LSB (Linux Standard Base)?

Not from a developers point of view, sorry. I'm just an amateur coder, I'm a sysadmin by profession.

But it is not that good if you do that with core libs like libstdc++.so.6 or libgcc_s.so.1

True, better don't touch the base libs, that's why it's good to compile against older versions, like you said.

[Kano]

@Cyber Killer

It is not that simple, basically you can ship libs if needed with your game/engine. But it is not that good if you do that with core libs like libstdc++.so.6 or libgcc_s.so.1 which happend with the Steam runtime for example. This can break 3d acceleration with Gallium based drivers. The other thing is if you want to run an app with a distro with older libc6 you have to compile it against that libc6. It usually does not have got any bad sideeffects on newer systems. But you don't need to use an old system to develop - just compile it for release in a more compatible way, a chroot is definitely enough. As mentioned before: Steam ships with runtime environments with lots of libs, if some are missing just tell em - maybe you did not notice that, but that's why you don't need to install so many 32 bit libs on your 64 bit system even if the games are 32 bit only.

[curaga]

I am a cross-platform developer for a proprietary program which runs on GNU/Linux, Windows and Mac OSX.
...
We're a small development team so we can not compile, package, and test on all major distributions (Ubuntu, Mint, Debian, Fedora, OpenSUSE, RHEL, CENTOS, etc.). It would simply be too time consuming.

It would be great if supporting many distributions would be as easy as supporting different versions of Windows, i.e compile once and ship all the library dependencies with your proprietary program.

Others already said how to pack libs; I'll just add that you can do a test run with one of my sw: http://sourceforge.net/projects/fift...er/files/v0.2/

Grab the binary release and see if it runs on your Ubuntu/Mint/Fedora/etc local system. I have done nothing special, C++ libs are static, less common C libraries are packed, only a few most common C libraries are expected to be on the system.

[AnonymousCoward]

Fixed that for you:
Compile your program (on a sufficiently old distro version), pack the binary + the dependent libs into a zip or whatever. Include a simple script to run the program:

#!/bin/bash

cd "`dirname $0`"
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./lib ./binary

(assuming you put the dependent libs inside 'lib' subdir in the programs directory)

Then when the user unpacks this, assuming he has a newer glibc and the architecture is ok (64bit/32bit), then the program will run and use system libs first or if they're not installed then the libs that you provided (just be sure to provide the dependencies of your dependencies too - it's generally a good idea to not use too many libs, better stick with 1 fairly complete framework). The only thing this differs from your windows example is the script to set the LD_LIBRARY_PATH for the binary.

No need to thank me ;-).

I vaguely remember trying this method about a year ago. I do not remember the exact reason, but I was unable to get it work reliably on different distributions. Then again, we have a fair amount of libraries, and those libraries have many dependencies themselves so it is likely that the error was on my part. I will once again revisit this in the near future.

On a related note, do you have any experience with the LSB (Linux Standard Base)?

I appreciate your input .

[bitman]

If a distro is so old that it's repos aren't available any more then nobody sane is using it anyway. As for lib versions - that is a project planning problem - you should stick to the lib features that are provided by library versions which are available on the oldest system that you are supporting. No, you don't get to pull that developer stunt of using the new and shiny features which have been just released in the new library version.

This is the way GNU/Linux is designed, live with it or recompile everything by hand.

You are very rigth. And fact that it is designed this way causes people lots of pain. And people run away from pain. And it does no good. Thats all..

[Cyber Killer]

And how is it a fix? Its ugly workaround for problem that should not exist. For some reason we have no problems building stuff on windows7 for xp. Also as if it was simple to build on old distro. How about i want 10 years old distro support? How about compiler being too old? How about libs too old? How about repos down? Its a joke, not a solution. Same problems stand for chroot.

If a distro is so old that it's repos aren't available any more then nobody sane is using it anyway. As for lib versions - that is a project planning problem - you should stick to the lib features that are provided by library versions which are available on the oldest system that you are supporting. No, you don't get to pull that developer stunt of using the new and shiny features which have been just released in the new library version.

This is the way GNU/Linux is designed, live with it or recompile everything by hand.

[bitman]

You don't need to do a full install of another distro, you can use 32/64 bit chroot as well if you only want to compile it.

Fixed that for you:
Compile your program (on a sufficiently old distro version)

And how is it a fix? Its ugly workaround for problem that should not exist. For some reason we have no problems building stuff on windows7 for xp. Also as if it was simple to build on old distro. How about i want 10 years old distro support? How about compiler being too old? How about libs too old? How about repos down? Its a joke, not a solution. Same problems stand for chroot.