On 12 Dec 2014, at 09:50, Willem Jan Withagen <wjw at 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.
>>
>> 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.
> 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.
-Dimitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141212/e6ad6396/attachment.sig>