This is the mail archive of the
mailing list for the glibc project.
[Bug build/13810] install_root broken for install-headers
- From: "carlos at systemhalted dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 06 Mar 2012 15:37:38 +0000
- Subject: [Bug build/13810] install_root broken for install-headers
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- 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.