On Tue, 2004-08-31 at 14:20, Stephen J Smoogen wrote:
I would add the c++ and the ncurses from FC1 'just-in-case' to your
/usr/local/games/fc1glibc tree also. use the directions jakub gave in
the previous email using rpm2cpio.
I am guessing that these will NOT fix the problem.. but it would be best
to get those out of the way right now. Nothing better to avoid a
glibc/kernel finger pointing match as quickly as possible. ;).
Aside from ncurses in the case of the static build using FC1
there don't appear to be any additional open files that have been
missed. With respect to ncurses, I believe it is only used to create
the status display of the server output in the shell from which it was
I matched all this against the output from ldd and I couldn't find a
smoking gun. It looks as if Jakub's trick worked flawlessly and
everything that would've been FC1 specific has been captured and put to
work. Could this indicate that the kernel is the problem or more
specifically the implementation of the FPU as you have suggested Alan?
I am heading towards that in my case. My view will be that the server
code is written expecting something that 2.4.xx gives FPU wise and
2.6.xx gives differently. The code is closed sourced? If it isnt it
would be interesting to find out where it is goofy now.. because it
might affect other people doing scientific code who assume that their
code works on 2.4 it will work smae on 2.6
I did try to install the most recent FC1 kernel rpms for
2.4.22-1.2199.nptl as well, but it told me a newer kernel version is
already installed and subsequently aborted the installation. Does
anyone have any suggestions?
rpm -ivh --force <kernel.rpm>
Check grub.conf to make sure it didnt break anything.
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 | PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545