RE: [SLE] LOKI Games on 10.0
![](https://seccdn.libravatar.org/avatar/22947ab22ceab046d7aa4544209c8e76.jpg?s=120&d=mm&r=g)
|-----Original Message----- |From: Mike McMullin [mailto:mwmcmlln@mnsi.net] |Sent: 20. mars 2006 00:19 |To: SLE |Subject: [SLE] LOKI Games on 10.0 was | | I've found that for the titles that I have they install in 10.0 and |9.3 but seg-fault. I see there's something on source forge |about patching the games. I hope it's that simple | No it is not that simple. the major problem is that many of the DSO's needed for running the games have changed a lot since they were built. Try getting the game up on an older system and do a ldd <path to binary> then ensure you have all the same DSO's available and then use modules to provide a similar environment, then load the game as a module and try running it. I got Quake3 Arena working this way on Suse9.3. If you still want to give it a test have a look at http://modules.sourceforge.net/ The glibc abi changes very often and few of the developers seem to be concerned about backwards compatibility. This may be a good point concering evolution and forcing developers to fresh up their code, but for us maintaining legacy code and horrendoulsy expensive software that we do not afford to upgrade all the time, this is a "pain in the ass" and showstopper. This affects everything built with gcc. There are still many RedHat AS2.1 customers out there because their code needs glibc2.2 Linux is still a terrible development platform for commercial software. There is no easy way of releasing supported, certified binaries in a distribution-independent manner. The clumsy workaround is to compile only object-files for distribution and post link them on the various destination platforms, but it requires development tools installed and a more complex installation procedure. -- MortenB - "Linux HPC application support/porting for 8 years"
![](https://seccdn.libravatar.org/avatar/5c786b1b80718534429c90c4126cd5ab.jpg?s=120&d=mm&r=g)
On Mon, 20 Mar 2006 09:11:42 +0100, Morten Bjørnsvik wrote:
and few of the developers seem to be concerned about backwards compatibility.
This just isn't true. glibc developers try very hard to maintain backwards compatibility whereever they can. Guess why the glibc maintainers adopted and extended the ELF symbol versioning originating from SUN? Exactly to provide better backwards compatibility (OK, the other reason was a way to completely hide internal symbols).
This affects everything built with gcc.
Just not true in this global form!
Linux is still a terrible development platform for commercial software.
Ah, so the M$ C runtime library mess ad the dll hell are a better platform?
There is no easy way of releasing supported, certified binaries in a distribution-independent manner.
That's why LSB was created: to specify a common cross-distribution platform for commercial vendors to build on. Yes, it's not completely there yet, but I have faith it will. Philipp
participants (2)
-
Morten Bjørnsvik
-
Philipp Thomas