which glibc my "self extractable"/ binary is using? - Unix

This is a discussion on which glibc my "self extractable"/ binary is using? - Unix ; Hi all, I have a software setup which runs finely on RHEL 3/4 but fails on RH AS 2.1. saying xrealloc:"cannot reallocate 13958592 bytes (0) bytes allocated." immediate difference I can see here is RHEL 3/4 uses glibc 2.3.x and ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: which glibc my "self extractable"/ binary is using?

  1. which glibc my "self extractable"/ binary is using?

    Hi all,
    I have a software setup which runs finely on RHEL 3/4 but fails on
    RH AS 2.1. saying

    xrealloc:"cannot reallocate 13958592 bytes (0) bytes allocated."

    immediate difference I can see here is
    RHEL 3/4 uses glibc 2.3.x

    and
    RH AS 2.1 uses glibc 2.2.x

    firstly is this a problem of glibc?

    My seconds question is is there any way to detect which glibc my "self
    extractable" software setup or any other binary file is using?






  2. Re: which glibc my "self extractable"/ binary is using?

    On Nov 22, 10:30 pm, Neo wrote:
    > Hi all,
    > I have a software setup which runs finely on RHEL 3/4 but fails on
    > RH AS 2.1. saying
    >
    > xrealloc:"cannot reallocate 13958592 bytes (0) bytes allocated."
    >
    > immediate difference I can see here is
    > RHEL 3/4 uses glibc 2.3.x
    >
    > and
    > RH AS 2.1 uses glibc 2.2.x
    >
    > firstly is this a problem of glibc?


    Not likely.

    The error message indicates the program can't allocate memory. There
    are two possibilities:

    1. The broken system has less memory available. Run "free" to see the
    total amount of available memory and see whether it looks like a
    reasonable amount. Also try "ulimit -a" to see whether your memory
    usage is limited.

    2. Something else in the operating environment causes the program to
    need more memory on the broken system, possibly an unreasonable
    amount. If this is the case you'll have to debug your program to
    figure out why. The strace utility might help.

    > My seconds question is is there any way to detect which glibc my "self
    > extractable" software setup or any other binary file is using?


    man ldd

  3. Re: which glibc my "self extractable"/ binary is using?

    On Nov 23, 12:35 pm, fjbl...@yahoo.com wrote:
    > On Nov 22, 10:30 pm, Neo wrote:
    >
    > > Hi all,
    > > I have a software setup which runs finely on RHEL 3/4 but fails on
    > > RH AS 2.1. saying

    >
    > > xrealloc:"cannot reallocate 13958592 bytes (0) bytes allocated."

    >
    > > immediate difference I can see here is
    > > RHEL 3/4 uses glibc 2.3.x

    >
    > > and
    > > RH AS 2.1 uses glibc 2.2.x

    >
    > > firstly is this a problem of glibc?

    >
    > Not likely.
    >
    > The error message indicates the program can't allocate memory. There
    > are two possibilities:
    >
    > 1. The broken system has less memory available. Run "free" to see the
    > total amount of available memory and see whether it looks like a
    > reasonable amount. Also try "ulimit -a" to see whether your memory
    > usage is limited.
    >
    > 2. Something else in the operating environment causes the program to
    > need more memory on the broken system, possibly an unreasonable
    > amount. If this is the case you'll have to debug your program to
    > figure out why. The strace utility might help.
    >
    > > My seconds question is is there any way to detect which glibc my "self
    > > extractable" software setup or any other binary file is using?

    >
    > man ldd


    My file is a setup.sh file. It is a self extracting executable. ldd
    does not work on it

  4. Re: which glibc my "self extractable"/ binary is using?

    On Nov 23, 1:31 am, Neo wrote:

    > > > My seconds question is is there any way to detect which glibc my "self
    > > > extractable" software setup or any other binary file is using?

    >
    > > man ldd

    >
    > My file is a setup.sh file. It is a self extracting executable. ldd
    > does not work on it


    In which case it is not using glibc, per se. The shell is using
    glibc, and so are all the programs that the shell script runs. You
    could run ldd on them.

    strace, again, is likely to be helpful in figuring out what program
    runs out of memory.

+ Reply to Thread