[BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[Markus Trippelsdorf]

(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.:

 % make -j4 check
...
Summary of test results:
      1 FAIL
   1565 PASS
     20 UNSUPPORTED
      2 XFAIL
      2 XPASS


 % make -j4 check
...
make[2]: Entering directory '/home/markus/glibc/nptl'
/usr/bin/install -c -m 644 ../include/stdlib.h /usr/include/stdlib.h
/usr/bin/install: cannot remove '/usr/include/stdlib.h': Permission denied
make[2]: *** [../Makerules:1269: /usr/include/stdlib.h] Error 1
make[2]: Leaving directory '/home/markus/glibc/nptl'
make[1]: *** [Makefile:215: nptl/tests] Error 2
make[1]: Leaving directory '/home/markus/glibc'
make: *** [Makefile:9: check] Error 2

-- 
Markus

Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[Szabolcs Nagy]

On 14/12/16 13:39, 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.:
...
>  % make -j4 check
> ...
> make[2]: Entering directory '/home/markus/glibc/nptl'
> /usr/bin/install -c -m 644 ../include/stdlib.h /usr/include/stdlib.h
> /usr/bin/install: cannot remove '/usr/include/stdlib.h': Permission denied

i've run into this header issue a few times

but for me usually it was some toolchain issue:
some make dependencies are generated by gcc and
a path setup issue can easily cause gcc to find
standard headers in /usr/include instead of in
the new glibc and then make tries to rebuild
those headers. (there are libstdc++ headers with
include_next which can make gcc look at the wrong
place).

this is fragile and dangerous behaviour:
i'd prefer if glibc did not try to rebuild
out-of-date headers outside the build directory
during make or make check.

Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[Carlos O'Donell]

On 12/14/2016 08:39 AM, Markus Trippelsdorf wrote:
> (My sourceware.org/bugzilla/ account got blocked due to bogus SPAM
> warning. So I send the report directly to the list.)

https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_Bugzilla

If you continue to have any problems please contact me.

We want Bugzilla to work for everyone.

-- 
Cheers,
Carlos.

Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[Markus Trippelsdorf]

On 2016.12.14 at 12:10 -0500, Carlos O'Donell wrote:
> On 12/14/2016 08:39 AM, Markus Trippelsdorf wrote:
> > (My sourceware.org/bugzilla/ account got blocked due to bogus SPAM
> > warning. So I send the report directly to the list.)
> 
> https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_Bugzilla
> 
> If you continue to have any problems please contact me.
> 
> We want Bugzilla to work for everyone.

Thanks, Frank (fche) re-activated my account.
It looks like an over-aggressive spam filter didn't like my bug report

-- 
Markus

Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[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".

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[Florian Weimer]

* 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.

Re: [BUG] glibs tries to install bogus /usr/include/stdlib.h when "make check" is run twice

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

On 14 Dec 2016 18:30, Florian Weimer wrote:
> 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.

make allows us to check whether DESTDIR is even defined, so we can
reject `make install` while still allowing `make install DESTDIR=`.

disallowing undefined DESTDIR sounds fine to me.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]