This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Markus Trippelsdorf <markus at trippelsdorf dot de>, <libc-alpha at sourceware dot org>
- Date: Wed, 14 Dec 2016 18:30:22 +0100
- Subject: Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice
- Authentication-results: sourceware.org; auth=none
- References: <20161214133946.GB414@x4> <alpine.DEB.2.20.1612141724010.32751@digraph.polyomino.org.uk>
* Joseph Myers:
> On Wed, 14 Dec 2016, Markus Trippelsdorf wrote:
>
>> (My sourceware.org/bugzilla/ account got blocked due to bogus SPAM
>> warning. So I send the report directly to the list.)
>>
>> When one runs "make check" twice in a row, glibc tries to install
>> an internal header file to /usr/include/stdlib.h, e.g.:
>
> We've had problems reported before with bad attempts to install to system
> header directories, e.g. bug 13810.
>
> The strategy of installing via Makefile targets in the name of installed
> files seems fragile in that way. It's also problematic in other ways.
> When adding build-many-glibcs.py support for stripping installed shared
> libraries, it occurred to me that really we should have "make
> install-strip" support that build-many-glibcs.py could use - that's a
> standard target from the GNU Coding Standards. But having a single target
> defining how to create an installed file is in tension with the correct
> way to install it depending on whether you ran "make install" or "make
> install-strip".
Right. In addition, we should guard against “make install” with
DESTDIR="", so that developers do not corrupt their host system if the
installed ld.so is incompatible with the new libc.so or vice versa.