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

["tschwinge at sourceware dot org" <sourceware-bugzilla 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.