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

Re: [gembud] GLIBC_2.4 not found message



Pete,

Could be that your GLIBC is old or doesn't provide that version of
compatibility. Try:

%strings /lib64/tls/libc.so.6 | grep GLIBC

The FC5 system I compiled the 64 bit binaries on has /lib64/libc.so.6
(not the tls you show)
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_PRIVATE


% gcc --version
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)



The newer 32 bit FC7 system I built binaries on provides:

% gcc --version
gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)

% strings /lib/libc.so.6 | grep GLIBC
GLIBC_2.0
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_PRIVATE


If your GLIBC is below the 2.4, you can upgrade your runtime
environment.

Steve Chiswell
Unidata User Support

On Mon, 2007-08-27 at 13:50 -0400, address@hidden wrote:
> 
> Hi Steve.. 
> 
> Wow - thanks for the quick response!  But the libc.so.6 file exists
> and is recognized by the system ... 
> 
> ldd $GEMEXE/ntl  gives  libc.so.6 => /lib64/tls/libc.so.6 
> 
> The message "/lib64/tls/libc.so.6: version `GLIBC_2.4` not found
> (required by ntl)" 
> seems to indicate a version issue rather than if or not the file
> exists. 
> 
> Advice? 
> 
> Pete 
> 
> Steve Chiswell <address@hidden> wrote on 08/27/2007 01:24:09
> PM:
> 
> > Pete,
> > 
> > You can add the directory " /lib64/tls" to your LD_LIBRARY_PATH
> > environmental variable so that the runtime environment can find the
> > libc.so.6.
> > 
> > You can use the command "ldd $GEMEXE/ntl" to verify that all of the
> > required
> > system libraries are being found.
> > 
> > Steve Chiswell
> > Unidata User Support
> > 
> > 
> > On Mon, 2007-08-27 at 13:18 -0400, 
> > address@hidden wrote:
> > > 
> > > Hi all.. 
> > > 
> > > Installed GEMPAK 5.10.3 and after modifying the 
> > Gemenviron file and
> > > properly sourcing GEMPAK 5.10.3 in .cshrc get the message 
> > > 
> > > /lib64/tls/libc.so.6: version `GLIBC_2.4` not found 
> > (reguired by ntl) 
> > > 
> > > when typing "ntl".  This message also occurs for manual 
> > launching of
> > > any of the ntl programs such as nmap, garp, etc. 
> > > 
> > > Some useful info: 
> > >       * Performing a "which ntl" gives
> > >         the /internal1/peter/GEMPAK/GEMPAK5.10.
> > 3/os/linux64/bin/ntl
> > >         (so its pointing to the correct location) 
> > >       * The file /lib64/tls/libc.so.6 exists and is 
> > actually a link
> > >         to /lib64/tls/libc-2.3.4.so (which also exists)
> > > 
> > > 
> > > Have since reverted to GEMPAK 5.10.2 but in the meantime.. any
> > > thoughts on how to remedy this issue? 
> > > 
> > > Pete 
> > > 
> > > 
> > > 
> >
> ______________________________________________________________________
> > > 
> > > The information contained in this message is intended only for the
> > > personal and confidential use of the recipient(s) named 
> > above. If the
> > > reader of this message is not the intended recipient or an agent
> > > responsible for delivering it to the intended recipient, you are
> > > hereby notified that you have received this document in 
> > error and that
> > > any review, dissemination, distribution, or copying of 
> > this message is
> > > strictly prohibited. If you have received this 
> > communication in error,
> > > please notify us immediately, and delete the original message.
> > > 
> > > _______________________________________________
> > > gembud mailing list
> > > address@hidden
> > > For list information or to unsubscribe,  visit: http:
> > //www.unidata.ucar.edu/mailing_lists/ 
> > -- 
> > Steve Chiswell <address@hidden>
> > Unidata
> 
> 
> 
> ______________________________________________________________________
> 
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and that
> any review, dissemination, distribution, or copying of this message is
> strictly prohibited. If you have received this communication in error,
> please notify us immediately, and delete the original message.
> 
-- 
Steve Chiswell <address@hidden>
Unidata


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.