A plea to devs to fix the Linux 3.06 patch

PhilD · #1 February 1st, 2007, 06:18 PM

The latest (3.06) patch, in the Linux version, changed something subtle - the version of the standard C library (glibc) it requires. As a consequence, players who don't have a quite-up-to-date version of the library installed (I just checked the GNU page: 2.4 was apparently released around March, 2006; anybody with a system that's older than that is likely to not have upgraded their libc, as it's a perfect example of "if it ain't broke, don't fix it") cannot use the patch. As a consequence, this prevents them from playing in PBEM games. And as the standard C library is a pretty critical part of the system, upgrading it the wrong way could clearly break the whole system install; it doesn't look like there are pre-packaged versions of glibc 2.4 for my current Linux distribution (which is Ubuntu 6.06; again, not the latest, but 6.06 indicates it was released June, 2006; it's not exactly an antique piece of software).

I would like to know if the move to glibc 2.4 was really necessary. If the devs come up and say there was a good, feature-required, reason for the move to 2.4, then I'll stop complaining and try to find a way to upgrade my glibc. But if it isn't, it would really, really be appreciated if they could recompile a version which is compliant with what is announced on the Shrapnel website as "System Requirements" (namely: libc >= 2.1.92)...

(And note that, for the previous patch to 3.04, the initially distributed Linux version was missing a file or two - I'd like to be sure the patch testing is done properly and equally on all supported platforms...)

Johan K · #2 February 1st, 2007, 06:50 PM

There is a very simple reason for the new glibc. The old linux development computer got scrapped and replaced with a new one. This new computer doesn't work on old linux distros, so there is a new development environment with new libs.

Still I thought I managed to get rid of the glibc 2.4 requirement, but obviously that failed. That dependecy is not supposed to be there. I will upload another linux patch if I manage to fix it.

thejeff · #3 February 1st, 2007, 07:23 PM

Did you already make a change to the patch?
I just installed it as a test and it seems to work fine.

Debian unstable: /lib/libc-2.3.6.so

Wazooking · #4 February 1st, 2007, 09:17 PM

I also installed it on my slackware with libc-2.3.2.so
It ran fine using textmode.

Moritz Moeller-Herrmann · #5 February 5th, 2007, 07:49 PM

Well, I can confirm that the linux patch is broken on Debian unstable. How current do you have to get.

This has been broken for three days now already without a warning on the front page! I think this is not very good service to paying customers.

Gandalf Parker · #6 February 5th, 2007, 09:24 PM

Its not technically "broken".
glibc_2.4 is considered to be still testing phase by debian.
But its already in the standard releases for other linux (such as the os used by the devs).

Whether you consider debian to be careful, or overly slow, is a matter of discussion. Personally I like that debian is so careful about moving things from test to unstable to stable.

thejeff · #7 February 6th, 2007, 09:30 AM

Working fine on debian unstable here.

I'm not sure why. I don't have glibc_2.4, so I didn't expect it to work.

I wonder if there's some more subtle dependency going on.

Gandalf Parker · #8 February 6th, 2007, 04:20 PM

I think debian moved it up to unstable. But thats still not what most linux servers on the net will be using. Home users, sure, might decide to use the unstable or even the test versions. So its still likely to be a problem for anyone running a public server, or loading dominions to their shell account on one.

thejeff · #9 February 6th, 2007, 04:30 PM

Nope, I still have /lib/libc-2.3.6.so

I'd checked it from work, when I first heard about the problem. I only installed the patch so I could be another data point. I was completely surprised when it worked.

There's something else going on.

Gandalf Parker · #10 February 6th, 2007, 05:59 PM

LINUX TECHNICAL CRAP: stop reading here if you dont want a headache

try typing...
dom3 -Tv
and then try typing
/usr/local/games/dominions3/dom3_x86 -Tv
(or whatever the appropriate version is for you). See if they agree on the version number. You might have a link to an older version.

You might walk thru the links. That messed me up in the past and took awhile for me to figure out. Such as, on MY machine, there is a softlink on the $PATH
/usr/local/bin/dom3
and if I go to that directory and do an "ls -l dom3" thenI see
lrwxrwxrwx dom3 -> /usr/local/games/dominions3/dom3
and doing a "ls -l dom3" of /usr/local/games/dominions3/dom3 shows me that its a softlink to dom3_x86.

But on one patch, I found that the first link was hard instead of soft. It showed /usr/local/bin/dom3 as a file with a size. That meant that my upgrade to /usr/local/games/dominions3 was ok for all of the files except the executional one.

Gandalf Parker