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.
