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?
Maciej ?enczykowski wrote:
>> ./real.exe: /usr/pgi/linux86-64/6.0/lib/libpthread.so.0: version
>> `GLIBC_2.3.3' not found (required by /lib64/tls/librt.so.1)
>
>
> Ok, on my Centos 4.1 i386 system I see the following:
>
> [root@tcs lib]# strings /lib/libpthread-0.10.so | grep GLIBC_2.3
> GLIBC_2.3.2
> GLIBC_2.3
> [root@tcs lib]# strings /lib/librt-2.3.4.so | grep GLIBC_2.3
> GLIBC_2.3.4
> GLIBC_2.3.2
> [root@tcs lib]# strings /lib/tls/librt-2.3.4.so | grep GLIBC_2.3
> GLIBC_2.3.4
> GLIBC_2.3.3
> GLIBC_2.3.2
>
> Which leads me to believe that maybe we shouldn't be using the tls
> version...
>
> try running the program(s) with
>
> LD_ASSUME_KERNEL=2.x.y ./real.exe
>
> with different versions of x.y (basically from 2.2.y 2.4.y and 2.6.y)
> maybe some value will work :)
>
> or you can try temporarily renaming the offending
> /lib64/tls/librt.so.1 symlink/file
>
> Cheers,
> MaZe.
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
>
--
Snowman
