Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Dec 2014 00:24:49 +0100
From:      Willem Jan Withagen <wjw@digiware.nl>
To:        Dimitry Andric <dim@FreeBSD.org>
Cc:        "stable@freebsd.org" <stable@freebsd.org>
Subject:   Re: missing /usr/lib/libc_nonshared.a
Message-ID:  <548B7941.4080303@digiware.nl>
In-Reply-To: <E0E8E210-33D5-4287-8E9C-AA8AE3C21E50@FreeBSD.org>
References:  <54837FAC.801@digiware.nl> <548AAC45.8080800@digiware.nl> <E0E8E210-33D5-4287-8E9C-AA8AE3C21E50@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12-12-2014 16:12, Dimitry Andric wrote:
> On 12 Dec 2014, at 09:50, Willem Jan Withagen <wjw@digiware.nl> 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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?548B7941.4080303>