Re: [gentoo-user] Installing an old glibc to run a proprietary commercial tool (would that even help?)

[Kyle Bader]

Avoiding 1, 2, and 3 but thought I'd propose a 4 other than a virtual
machine.  Ask the vendor if they can provide a statically compiled
version, that way you don't have to worry about libc.  I dunno how
flexible the vendor is but its worth asking :)

On 10/30/09, Duncan Smith <duncanphilipnorman@×××××.com> wrote:
> The company I work for is using gentoo on all its machines.  We just
> got a license to a commercial tool which does not support gentoo.  The
> closest thing it supports is RHEL v4.
>
> Running any command provided by the tool results in an explosive
> memory leak (virtual memory hits 400G in 1 second, and continues to
> climb).
>
> I suspect the problem is that RHEL v4 uses =sys-libs/glibc-2.3.4,
> whereas we have =sys-libs/glibc-2.9_p20081201-r2 installed.
>
> I have three questions:
>  1. Am I posting to the right list?
>  2. Any idea what's going on?  Could it be something other than glibc
> causing the problem?
>  3. If it is glibc, is there some way to install glibc slotted?  Could
> I install an old version of glibc to some other lib folder (like
> /opt/lib64), and then use LD_LIBRARY_PATH somehow to get the tool to
> look there first?  How?
>
> Thanks for any help or ideas.
>
> Duncan
>
> P.S. In case it's useful, here is the output of ldd:
>         linux-vdso.so.1 =>  (0x00007fff9e3ff000)
>         libncurses.so.5 => /lib/libncurses.so.5 (0x00007f49c871b000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x00007f49c8503000)
>         libm.so.6 => /lib/libm.so.6 (0x00007f49c827e000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00007f49c807a000)
>         libc.so.6 => /lib/libc.so.6 (0x00007f49c7d07000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f49c897a000)
>
>

-- 
Sent from my mobile device


Kyle