This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
    /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
    /usr/bin/install -c -m 644
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/sigaction.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/sigset.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/siginfo.h
    /usr/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/bits/sigstack.h
    /usr/bin/install -c -m 644 ../nptl/sysdeps/pthread/bits/sigthread.h
    make[2]: Leaving directory

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
    .././scripts/mkinstalldirs /var/tmp/usr/include/rpcsvc
    /usr/bin/install -c -m 644 rpcsvc/bootparam.h
    .././scripts/mkinstalldirs /home/thomas/tmp/source/glibc/
    mkdir /home/thomas/tmp/source/glibc/
    gcc rpc_main.c -c [...]
    gcc rpc_sample.c -c [...]
    make[2]: *** No rule to make target
`/home/thomas/tmp/source/glibc/', needed by
`/home/thomas/tmp/source/glibc/'.  Stop.
    make[2]: Leaving directory
    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, 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:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]