[Bug build/13810] New: install_root broken for install-headers

[Bug build/13810] New: install_root broken for install-headers

[christer.solskogen at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13810

             Bug #: 13810
           Summary: install_root broken for install-headers
           Product: glibc
           Version: 2.14
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build
        AssignedTo: unassigned@sourceware.org
        ReportedBy: christer.solskogen@gmail.com
                CC: carlos@systemhalted.org
    Classification: Unclassified


"make install-headers install_root=/var/tmp" will try to copy the header files
to /usr as well if prefix=/usr. install_root does however work with "make
install install_root=/var/tmp" if you built glibc.

How to reproduce (at least on Debian Squeeze)

Download and unpack glibc-2.14.1.tar.xz. Create a out-of-tree
build-directory. Run configure. Output as follows:
../glibc-2.14.1/configure --prefix=/usr
....

make install-headers install_root=/var/tmp
....

make[2]: Entering directory `/home/solskogen/temp/glibc-2.14.1/signal'
/usr/bin/install -c -m 644 signal.h /usr/include/signal.h
/usr/bin/install: cannot remove `/usr/include/signal.h': Permission denied
make[2]: *** [/usr/include/signal.h] Error 1
make[2]: Leaving directory `/home/solskogen/temp/glibc-2.14.1/signal'
make[1]: *** [signal/install-headers] Error 2
make[1]: Leaving directory `/home/solskogen/temp/glibc-2.14.1'
make: *** [install-headers] Error 2

That said, *some* headers are installed at the right place:
/var/tmp/usr
/var/tmp/usr/include
/var/tmp/usr/include/setjmp.h
/var/tmp/usr/include/iconv.h
/var/tmp/usr/include/ieee754.h
/var/tmp/usr/include/langinfo.h
/var/tmp/usr/include/values.h
/var/tmp/usr/include/xlocale.h
/var/tmp/usr/include/math.h
/var/tmp/usr/include/features.h
/var/tmp/usr/include/assert.h
/var/tmp/usr/include/ctype.h
/var/tmp/usr/include/fpu_control.h
/var/tmp/usr/include/libintl.h
/var/tmp/usr/include/tgmath.h
/var/tmp/usr/include/gnu-versions.h
/var/tmp/usr/include/limits.h
/var/tmp/usr/include/gconv.h
/var/tmp/usr/include/gnu
/var/tmp/usr/include/gnu/libc-version.h
/var/tmp/usr/include/gnu/lib-names.h
/var/tmp/usr/include/bits
/var/tmp/usr/include/bits/setjmp.h
/var/tmp/usr/include/bits/huge_valf.h
/var/tmp/usr/include/bits/mathinline.h
/var/tmp/usr/include/bits/setjmp2.h
/var/tmp/usr/include/bits/mathcalls.h
/var/tmp/usr/include/bits/xopen_lim.h
/var/tmp/usr/include/bits/inf.h
/var/tmp/usr/include/bits/libc-lock.h
/var/tmp/usr/include/bits/huge_vall.h
/var/tmp/usr/include/bits/nan.h
/var/tmp/usr/include/bits/cmathcalls.h
/var/tmp/usr/include/bits/mathdef.h
/var/tmp/usr/include/bits/fenvinline.h
/var/tmp/usr/include/bits/huge_val.h
/var/tmp/usr/include/bits/locale.h
/var/tmp/usr/include/bits/fenv.h
/var/tmp/usr/include/nl_types.h
/var/tmp/usr/include/complex.h
/var/tmp/usr/include/locale.h
/var/tmp/usr/include/fenv.h

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug build/13810] install_root broken for install-headers

[carlos at systemhalted dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13810

Carlos O'Donell <carlos at systemhalted dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
         AssignedTo|unassigned at sourceware    |carlos at systemhalted dot
                   |dot org                     |org

--- Comment #1 from Carlos O'Donell <carlos at systemhalted dot org> 2012-03-05 22:57:56 UTC ---
We can't support any version but those specifically released by the glibc team.

I've tried a variety of configure and "make install-headers" options, but I'm
not able to reproduce the problem you are seeing.

Could you please try reproducing using trunk?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug build/13810] install_root broken for install-headers

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13810

Thomas Schwinge <tschwinge at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at sourceware dot
                   |                            |org

--- Comment #2 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-03-06 09:23:36 UTC ---
I'm also not able to reproduce this with sources as per the Git
glibc-2.14.1 tag:

    [...]
    make[2]: Entering directory
`/media/data/home/thomas/tmp/source/glibc/glibc-2.14.1/signal'
    /usr/bin/install -c -m 644 signal.h /var/tmp/usr/include/signal.h
    .././scripts/mkinstalldirs /var/tmp/usr/include/sys
    mkdir /var/tmp/usr/include/sys
    /usr/bin/install -c -m 644 sys/signal.h /var/tmp/usr/include/sys/signal.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/signum.h
/var/tmp/usr/include/bits/signum.h
    /usr/bin/install -c -m 644
../sysdeps/unix/sysv/linux/x86_64/bits/sigcontext.h
/var/tmp/usr/include/bits/sigcontext.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/sigaction.h
/var/tmp/usr/include/bits/sigaction.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/sigset.h
/var/tmp/usr/include/bits/sigset.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/siginfo.h
/var/tmp/usr/include/bits/siginfo.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/sigstack.h
/var/tmp/usr/include/bits/sigstack.h
    /usr/bin/install -c -m 644 ../nptl/sysdeps/pthread/bits/sigthread.h
/var/tmp/usr/include/bits/sigthread.h
    make[2]: Leaving directory
`/media/data/home/thomas/tmp/source/glibc/glibc-2.14.1/signal'
    [...]

Christer, can you really reproduce the breakage you report from clean
sources and clean build tree?


But what does happen for me is that the ``make install-headers''
invocation breaks down later on for sunrpc/install-headers, when it tries
to *build* the rpcgen tool.  This also happens with the current Git
master branch, and thus is a bug on its own.  It's not related to the
recent sunrpc deprecation, but also appears with the Git glibc-2.11 tag,
for example.  Carlos, have you seen this, too?

    [...]
    /usr/bin/install -c -m 644 rpcsvc/key_prot.x
/var/tmp/usr/include/rpcsvc/key_prot.x
    .././scripts/mkinstalldirs /var/tmp/usr/include/rpcsvc
    /usr/bin/install -c -m 644 rpcsvc/bootparam.h
/var/tmp/usr/include/rpcsvc/bootparam.h
    .././scripts/mkinstalldirs /home/thomas/tmp/source/glibc/tmp.build/sunrpc
    mkdir /home/thomas/tmp/source/glibc/tmp.build/sunrpc
    gcc rpc_main.c -c [...]
    [...]
    gcc rpc_sample.c -c [...]
    make[2]: *** No rule to make target
`/home/thomas/tmp/source/glibc/tmp.build/elf/soinit.os', needed by
`/home/thomas/tmp/source/glibc/tmp.build/libc.so'.  Stop.
    make[2]: Leaving directory
`/media/data/home/thomas/tmp/source/glibc/tmp/sunrpc'
    make[1]: *** [sunrpc/install-headers] Error 2
    make[1]: Leaving directory `/media/data/home/thomas/tmp/source/glibc/tmp'
    make: *** [install-headers] Error 2

Comparing to a regular build's log: there, these object files are built
during the ``others'' make pass, before attempting to link rpcgen (for
which the object files are obviously a prerequisite).  Then, rpcgen would
be invoked (using the newly build ld.so, libc, etc. -- which is missing
in the install-headers case) to generate several *.c and *.h files, the
latter of which are to be installed into [PREFIX]/include/rpcsvc/ by
means of ``headers += $(rpcsvc:%.x=rpcsvc/%.h)''.  This is guarded by
``ifeq (no,$(cross-compiling))'', so running ``make install-headers
install_root=/var/tmp cross-compiling=yes'' works fine for me.  Assuming
that the SunRPC headers are not needed in the case where you'd use ``make
install-headers'' (for bootstrapping a toolchain), I think it'd be fine
to not only guard this headers amendmend by cross-compiling == no, but
also for the install-headers case.  The option of linking rpcgen against
the build/host system's C library seems overkill to me.  If we agree this
is the way forward, I'll see about creating a patch for this issue.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug build/13810] install_root broken for install-headers

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13810

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-03-06 14:09:22 UTC ---
On Tue, 6 Mar 2012, tschwinge at sourceware dot org wrote:

> install_root=/var/tmp cross-compiling=yes'' works fine for me.  Assuming
> that the SunRPC headers are not needed in the case where you'd use ``make
> install-headers'' (for bootstrapping a toolchain), I think it'd be fine
> to not only guard this headers amendmend by cross-compiling == no, but
> also for the install-headers case.  The option of linking rpcgen against
> the build/host system's C library seems overkill to me.  If we agree this
> is the way forward, I'll see about creating a patch for this issue.

"install-headers" is not the same as "install the headers needed for 
bootstrapping"; it doesn't install all of those.  Merging the 
install-bootstrap-headers=yes support from EGLIBC (implemented by Jim 
Blandy in 2007-02) is on my list of possible enhancements; note that 
support already has an appropriate conditional for the sunrpc headers.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug build/13810] install_root broken for install-headers

[christer.solskogen at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13810

Christer Solskogen <christer.solskogen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever Confirmed|1                           |0

--- Comment #4 from Christer Solskogen <christer.solskogen at gmail dot com> 2012-03-06 14:18:58 UTC ---
I *think* I know why now. I think the fault is make. 
Because this works:

With GNU Make 3.82

configure...
cat >> configparms<< EOF
install-bootstrap-headers=yes
cross-compiling=yes
install_root=$PWD/dest
EOF
make install-headers

With 
GNU Make 3.81
configure...
make install-headers install-bootstrap-headers=yes cross-compiling=yes
install_root=$PWD/dest

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug build/13810] install_root broken for install-headers

[carlos at systemhalted dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13810

--- Comment #5 from Carlos O'Donell <carlos at systemhalted dot org> 2012-03-06 15:37:38 UTC ---
(In reply to comment #2)
> I'm also not able to reproduce this with sources as per the Git
> glibc-2.14.1 tag:

Thanks for checking this Thomas.

> Christer, can you really reproduce the breakage you report from clean
> sources and clean build tree?
> 
> 
> But what does happen for me is that the ``make install-headers''
> invocation breaks down later on for sunrpc/install-headers, when it tries
> to *build* the rpcgen tool.  This also happens with the current Git
> master branch, and thus is a bug on its own.  It's not related to the
> recent sunrpc deprecation, but also appears with the Git glibc-2.11 tag,
> for example.  Carlos, have you seen this, too?

I have, but I ignored it because it wasn't related to this problem.

> Comparing to a regular build's log: there, these object files are built
> during the ``others'' make pass, before attempting to link rpcgen (for
> which the object files are obviously a prerequisite).  Then, rpcgen would
> be invoked (using the newly build ld.so, libc, etc. -- which is missing
> in the install-headers case) to generate several *.c and *.h files, the
> latter of which are to be installed into [PREFIX]/include/rpcsvc/ by
> means of ``headers += $(rpcsvc:%.x=rpcsvc/%.h)''.  This is guarded by
> ``ifeq (no,$(cross-compiling))'', so running ``make install-headers
> install_root=/var/tmp cross-compiling=yes'' works fine for me.  Assuming
> that the SunRPC headers are not needed in the case where you'd use ``make
> install-headers'' (for bootstrapping a toolchain), I think it'd be fine
> to not only guard this headers amendmend by cross-compiling == no, but
> also for the install-headers case.  The option of linking rpcgen against
> the build/host system's C library seems overkill to me.  If we agree this
> is the way forward, I'll see about creating a patch for this issue.

Yes, as Joseph says this problem is fixed in EGLIBC.

If you want to crib the change from EGLIBC I'd be more than happy to review.

However, that is a different issue.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug build/13810] install_root broken for install-headers

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13810

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.