This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Hanging conftest
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Eric Blake <eblake at redhat dot com>
- Cc: Michal Privoznik <mprivozn at redhat dot com>, bug-gnulib at gnu dot org, libc-alpha at sourceware dot org
- Date: Wed, 4 Dec 2013 09:35:53 +0530
- Subject: Re: Hanging conftest
- Authentication-results: sourceware.org; auth=none
- References: <529624A0 dot 2020106 at redhat dot com> <52962B78 dot 20003 at redhat dot com> <20131128050020 dot GE20495 at spoyarek dot pnq dot redhat dot com> <52974B01 dot 9000704 at redhat dot com> <5297548F dot 7020902 at redhat dot com> <529E0FF4 dot 8000004 at redhat dot com> <20131204033145 dot GM14845 at spoyarek dot pnq dot redhat dot com> <529EA7A5 dot 3060306 at redhat dot com>
On Tue, Dec 03, 2013 at 08:55:17PM -0700, Eric Blake wrote:
> MALLOC_CHECK_ in the environment at the start of ./configure affects
> hundreds or even thousands of processes. mallopt() within a single
> conftest affects only the one process. I found it slightly easier to
> use mallopt() within the conftest code than to figure out how to ensure
> I was injecting MALLOC_CHECK_ into the environment of the m4 code that
> runs the conftest program without also leaking into the environment of
> the rest of the configure script.
OK, thanks for explaining your use case.
> > However, it looks like we don't do __malloc_check_init
> > for M_CHECK_ACTION, which is what initializes the additional checks.
> > Does anyone know if it is intentional? It looks like a bug to me.
>
> That's more a matter for glibc to decide; for now, all I was worried
> about was patching gnulib in a manner that would prevent configure from
Right, that question was in fact pointed at glibc maintainers.
Siddhesh