I just got through reading several articles on the assume kernel, and
your explaination was much more understandable than all of the others.
After seeing it is just an environment variable that can be set, most
likely the scripts that call the .exe's will handle that accordingly.
I'm just not up to speed on all the scripts that my buddy has installed
to run this behemoth. I did run one test, and it passed without any
problems, so I'm pretty comfortable that will most likely prevent me
from dropping back a version or 2 and going to the 32-bit version. If I
can get one more fortran piece of code to build a shared object, I'll be
happy as a pig in slop :-) That part is going to take a bit more doing
tho I expect, as its talking about a relocated object that can't be
linked to something or other. Several other ideas have failed to build
the thing including wrapit from the NCL libraries. Once I get past this
part, if you don't mind me calling on you, I'd appreciate you telling me
what can be done with the one little fortran script that does the .so.
Maciej ?enczykowski wrote:
>
> 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.
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
>
--
Snowman
