Re: Bug? Older 32 bit program (CivCTP) no longer works under 64 bit kernel

[Ken Moffat <zarniwhoop@ntlworld.com>]

On Thu, May 15, 2014 at 08:24:05PM -0500, David Hagood wrote:
> I have an old native Linux 32 bit copy of Civilization: Call to Power. It
> used to work under a 64 bit environment back in the 3.0.x days. However,
> under recent versions (>3.5) it no longer runs - it complains that it cannot
> find certain files in the directory. The exact same code will run just fine
> under a 32 bit version of 3.11. I have a Pentium II as well as the Core 2
> Duo, both running Ubuntu 14.04, same version of the kernel other than one is
> 32 bit and one is 64 bit. I've copied the files over from the 32 bit
> machine, where it runs, to the 64 bit machine, where it does not. I've even
> gone so far as to copy all the system 32 bit libraries into the CivCTP
> directory, and forced the program to use them (including using the
> ld-linux.so loader from that directory) - so in theory it's all the same
> user space libraries running - the only difference that I can see is that
> one kernel is 64 bit and one is 32 bit.
> 
> Running strace on the program shows that the directories being searched for
> game assets are corrupted:
> 
> 16218 stat64("/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt",
> <unfinished ...>
> 
> Note the "englisish" rather than "english".
> 
> I'm looking for any suggestions on where to look for what might cause such
> an issue - what can I do to start tracking this down.

 I've no ideas about what part of the kernel is causing this, so
I'll just offer you some thoughts on how to track it down.  At a
guess, you will have to run 'git bisect' to nail which change broke
this (or alternatively which change exposed a latent problem).

 Bisection is fairly well covered on google, for example it finds
http://landley.net/writing/git-bisect-howto.html

 The corrupt filename looks (to me, with no experience) like
something which might be in the filesystem area.  It probably isn't,
but I don't recall anything at all like this, so I'd better ask - are
you using an uncommon filesystem for this data ?  This looks like
such a grievous fault that I would expect someone to have noticed it
between 3.5.0 and now.

 And, have you tried any recent kernels (e.g. 3.14.4) to confirm
that the problem still exists ?  If it turns out that somebody
already fixed it, that would save you a lot of effort.

 You will need a network connection to clone linus' tree, and some
space for it.  And git, of course.  To bisect, you should build in
the git tree, AND set CONFIG_LOCALVERSION_AUTO - in
 General setup
  [ ] Automatically append version information to the version

so that the kernel version, and the version in /lib/modules, will
add -XXXXX-gYYYYYYYY information to each non-release install - that
is useful when you are bisecting, so that each set of modules is
kept separate.  See e.g.
http://yarchive.net/comp/linux/CONFIG_LOCALVERSION_AUTO.html

 It might speed this up if you can minimise the kernel config
(distros tend to build the whole kitchen sink as modules) - the
fewer unnecessary things you build, the less time it takes.

 Does it work on 3.4.0 ?  I know 3.4 is supported, and therefore
there are continuing releases with backported fixes, but for
bisection it is easiest to start testing with .0 releases.  If it
doesn't work there (I'm unclear if 3.5 was the earliest post-3.0
kernel that you tried), find which was the last .0 kernel where it
worked.  You can then label that version as "good", e.g.
 git bisect good v3.4 [ or whichever version - without the .0 ].

 Once you are certain which .0 version was the last which worked,
the next can be marked as bad, e.g. v3.5 - and then you bisect.

 Do not be surprised if the kernel identifies itself as an earlier
version than the last good one - see Linus's post referenced at
yarchive.net above.  And good luck, bisection is usually tedious.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce