On Sat, 1 Oct 2005, Sam Drinkard wrote: > MaZe, > > I tried your suggestion, and it appears that with LD_ASSUME_KERNEL=2.4.1 the > things quit complaining about the library. I have no idea what is happening > in that respect, but something happens. I'm not seeing the "normal" message > from real.exe about not having an input namelist however, so I may or may not > work. running the exe's does however give me a "starting wrf task 0 of 1", > and the other .exe's , real/ndown, etc., also do the same thing. I'll have to > muck around in the startup script and see what happens when changing those. > Also, since mpi is not running, nor do I have OMP set, it *might* just take > off and work. I've got to pass this info to my compadre in crime and let him > know, as there maybe some other things to look at besides the message passing > protocols. I really thank you for the suggestion. > > On another note, you indicate perhaps we should not be using the tls version? > Can you expand on that a bit as to why, and what the tls is? ok, tls is 'thread local storage' - basically this is a memory area which is not shared between different threads of the application (very useful). This is much easier(?)/requires(?) kernel support to work. Which apparently was introduced in kernel 2.4.2. Furthermore this kernel support needs to be also supported/used by the threading libraries. If everything is beautiful then a new kernel / library / loader will automagically detect whether tls is supported on the current machine or not and run with or without tls accordingly. However this seems to often be broken for stuff compiled a long time ago or with different compilers (non gcc). As such via the LD_ASSUME_KERNEL=2.4.1 argument you are telling the online linker/loader (ld-linux) that the kernel you are using is too old to support tls. Thus ld-linux (which does a lot of magic by first looking for /lib libs in /lib/ix86/tls then /lib/tls then /lib/ix86 and only then /lib for the proper x value for your cpu) skips the tls directories which contain the tls-enabled libraries - thus effectively turning of tls support (and possibly other stuff). I guessed this was the solution based on looking through the strings output of the different libraries from your error message. The fact that I apparently hit was in the end pure luck (and a very good educated guess...) I couldn't exactly duplicate and/or explain my reasoning (although I have had other programs, like iscan, which only work with the LD_KERNEL_ASSUME=2.4.1 option) You can also try 'export LD_ASSUME_KERNEL=2.4.1' somewhere at the top of whatever runscript the programs are using. Cheers, MaZe.