On Fri, 2009-10-30 at 10:01 -0400, Duncan Smith 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?
You are just just as likely to get support from Gentoo about software we have no access to as your distributer is to support Gentoo. > 2. Any idea what's going on? Could it be something other than glibc > causing the problem? It could be one of a hundred million things. Without access to the program it's really hard to tell. > 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? You can't have multiple versions of glibc. And you can't downgrade glibc. Attempting to do so may result in having more than just that program misbehaving ;) My suggestion, for your sanity and support: if you insist on Gentoo then at least run RHEL4 (or CentOS or whatever) inside a virtual machine and run your app from there.
