Re: turn off VDSO on glibc side

[heroxbd <heroxbd at gentoo dot org>]

Dear Carlos,

"Carlos O'Donell" <carlos@redhat.com> writes:

> On 07/03/2013 04:05 AM, heroxbd wrote:
>>> or upgrade your kernel to one that isn't buggy :p
>> 
>> Yeah. At the same time, RHEL is our main use case for Prefix/libc where
>> glibc is too old. I think doing the patch on our side is better than
>> getting users to upgrade their already-set-up-but-easy-to-break or
>> hard-to-request-kernel-upgrade-VPS systems.
>
> What problem are you trying to solve?

> May I ask why you want a new glibc?

In a sub project of Gentoo called Prefix, we allow normal user to
install a Gentoo in a prefix[1]. In the Linux variant of Prefix, we
share glibc and linux kernel with the host, while build other parts from
Gentoo portage tree.

glibc from RHEL5, however, is 2.5 and do not have support for
fortify. This causes a variety of issues[2,3,4], some of them are
resolved with a dirty hack[4], some of them are still hidden.

To address this issue, we are trying to get independent from host
glibc[5]. Then we met this vdso bug in RHEL-5.6 kernel.

> I ask because if you just want a new compiler you could use the 
> Developer Toolset (DTS) to get the benefit of newer compilers,
> linkers, and tools without the need to recompile the entire base
> runtime (uses the system glibc).

Thanks for the offer. I am wondering as a set of tools built around
system glibc, how DTS handles fortify. Does it disable it completely?

> If you want new API's from glibc, then that's a problem DTS
> can't fix.

I am afraid so.

Cheers,
Benda

1. http://prefix.gentoo.org
2. http://thread.gmane.org/gmane.linux.gentoo.alt/6459
3. http://thread.gmane.org/gmane.linux.gentoo.alt/6110
4. https://bugs.gentoo.org/show_bug.cgi?id=289757
5. http://wiki.gentoo.org/wiki/Prefix/libc