From owner-freebsd-stable@FreeBSD.ORG Sat Dec 13 00:39:58 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 098BF232; Sat, 13 Dec 2014 00:39:58 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8331A6B; Sat, 13 Dec 2014 00:39:57 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 734F216A406; Sat, 13 Dec 2014 01:39:53 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9RRG8-6BUP7; Sat, 13 Dec 2014 01:34:52 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:7c0e:cd5d:381f:40b2] (unknown [IPv6:2001:4cb8:3:1:7c0e:cd5d:381f:40b2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 56C1D16A402; Sat, 13 Dec 2014 00:24:50 +0100 (CET) Message-ID: <548B7941.4080303@digiware.nl> Date: Sat, 13 Dec 2014 00:24:49 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: missing /usr/lib/libc_nonshared.a References: <54837FAC.801@digiware.nl> <548AAC45.8080800@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 00:39:58 -0000 On 12-12-2014 16:12, Dimitry Andric wrote: > On 12 Dec 2014, at 09:50, Willem Jan Withagen wrote: >> >> On 2014-12-06 23:14, Willem Jan Withagen wrote: >>> Still trying to upgrade from 9.3 to 10.1, which seemed to get going. >>> Completely started over again with cleaned out /etc/{make.src}.conf. >>> Then build/installed 9.3 again which also included clang this time. >>> >>> but building the toolchain generates: >>> -------------------------------------------------------------- >>>>>> stage 2.3: build tools >>> -------------------------------------------------------------- > ... >>> cc -o gethost -L/usr/obj/usr/src10/tmp/legacy/usr/lib -O2 -pipe -I. >>> -I/usr/src10/bin/csh -I/usr/src10/bin/csh/../../contrib/tcsh >>> -D_PATH_TCSHELL='"/bin/csh"' -std=gnu99 >>> -I/usr/obj/usr/src10/tmp/legacy/usr/include >>> /usr/src10/bin/csh/../../contrib/tcsh/gethost.c >>> /usr/bin/ld: cannot find /usr/lib/libc_nonshared.a >>> *** Error code 1 >>> ----------------- >>> >>> Now I can fudge around this, by getting this lib from another 10.x >>> system, but changes are that things are nog 100% compatible. >>> >>> So how do I get this lib first, before starting to build bin/csh. > > This part of buildworld uses the compiler, include files, linker and > libraries from your existing system. E.g. it is normal for this part to > use /usr/bin/ld, /usr/lib, and so on. > > On a 9.3 system, I would not expect ld to search for libc_nonshared.a, > since that is a feature introduced in 10.0, where /usr/lib/libc.so was > changed from a symlink to a linker script. > > Can you please check on your system, what /usr/lib/libc.so is? Is it a > symlink or a plain text file? If it is the latter, your system is most > likely polluted with 10.x installation left-overs. Right, then this is a consequence of something I'm trying to repair.... I thought I build world+kernel. So I installed kernel and rebooted, Only to find out that instalworld did not make it very far. After that I started fidgeting, hoping to somehow get to 10.1. So my guess is that things get very upset if one is building on a system with a 10.1 kernel, and a 9.3 world. >>> The other question is: >>> why am I still using gcc for the toolchain even since I now have >>> clang onboard? > > For the early stages of buildworld, e.g. bootstrap-tools, build-tools > and cross-tools, it is normal that the system compiler is used, e.g. > just /usr/bin/cc. > > On a 9.x system, that is usually gcc, but this does not say anything > about the later stages of buildworld, which will be built with the > toolchain produced in the cross-tools stage. For 10.x, that is usually > clang. > > >> Turn out that the only way I could cheat make in to going anywhere was to: >> cd /usr/src/lib/libc_nonshared >> make >> make install >> >> And only then the build seems to progress. > > I think it is better to inspect your /usr/lib/libc.so, and find out if > it is accidentally replaced by a linker script. /* $FreeBSD: stable/10/lib/libc/libc.ldscript 258398 2013-11-20 20:24:59Z peter $ */ GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a /usr/lib/libssp_nonshared.a ) So that seem to be the case >> This all even though the /usr/obj tree holds: >> [~] wjw > locate libc_non >> /usr/objs/amd64/usr/src10/lib/libc_nonshared >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/.depend >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__iconv.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__iconv_free_list.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__iconv_get_list.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/__stub.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_canonicalize.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_close.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_open.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_open_into.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconv_set_relocation_prefix.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconvctl.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/iconvlist.o >> /usr/objs/amd64/usr/src10/lib/libc_nonshared/libc_nonshared.a >> /usr/objs/amd64/usr/src10/tmp/usr/lib/libc_nonshared.a >> >> And I would expect csh to be build against: >> /usr/objs/amd64/usr/src10/tmp/usr/lib/libc_nonshared.a >> >> But for what happened, I conclude that it is linked against /usr/lib. > > During the early stages of buildworld, this is completely normal, and > expected. I just manually went into /usr/src/lib/libc_nonshared and ran make make install And now I'm trying to build world on a 1.8GHz atom, so that is slow.... Even just compiling clang is already a serious undertaking. --WjW