NetBSD Problem Report #47353

From martin@duskware.de  Tue Dec 18 19:36:47 2012
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 15CBD63E856
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 18 Dec 2012 19:36:47 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: subtle make (or makefile?) bug in mknative
X-Send-Pr-Version: 3.95

>Number:         47353
>Category:       toolchain
>Synopsis:       subtle make (or makefile?) bug in mknative
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 18 19:40:00 +0000 2012
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.15
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD night-porter.duskware.de 6.0 NetBSD 6.0 (PORTER) #3: Sat Oct 13 16:04:32 CEST 2012 martin@night-porter.duskware.de:/usr/src-6/sys/arch/i386/compile/PORTER i386
Architecture: i386
Machine: i386
>Description:

When doing a "mknative" to adapt our static build environment to changed libc
features (or after changes in gcc) the procedure documented in
src/tools/gcc/README.mknative mostly works (with one minor nit: in all
nbmake-$arch invocations that set MKGCC=no you have to add HAVE_GCC=45 [or
whatever your in-tree gcc version is]), as long as in step 2 (build.sh tools)
you used a -M argument to build.sh.

If instead you used a -O argument, step 3 fails with something like:

configure: creating ./config.status
config.status: creating Makefile
Creating files needed for libgcc by a native bootstrap build.
nbgmake: /usr/obj/ia64/tools/gcc/build/gcc/Makefile: No such file or directory
nbgmake: *** No rule to make target
`/usr/obj/ia64/tools/gcc/build/gcc/Makefile'.  Stop.
ABORT: getvars gcc/Makefile INCLUDES LIB2ADD LIB2ADDEH LIB2ADD_ST LIB1ASMFUNCS

This seems to happen because the "getvars" shell helper function is invoked
with a relative makefile path "gcc/Makefile" which magically gets transformed
into a bogus objdir reference.

>How-To-Repeat:

s/a

>Fix:
n/a

Home	PR Database Search