On Friday 30 October 2009 23:52:10 Kyle Bader wrote: > 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 :)
If it's a somewhat critical machine for business, just drop a new stand-alone box running RHEL4. Critical machines usually generate|save more cash than the cost of the box they run on > On 10/30/09, Duncan Smith <duncanphilipnor...@gmail.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) > -- alan dot mckinnon at gmail dot com
