Recommendation(s)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux