On Tue, 2004-08-31 at 14:20, Stephen J Smoogen wrote:
/usr/lib/libstdc++.so.5.0.5
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 libraries, 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 launched.
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@xxxxxxxx Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
