Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Jun 2000 16:43:41 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Kris Kennaway <kris@FreeBSD.ORG>
Cc:        current@FreeBSD.ORG
Subject:   Re: 4.x buildworlds broken on -current
Message-ID:  <Pine.BSF.4.21.0006111630560.972-100000@besplex.bde.org>
In-Reply-To: <Pine.BSF.4.21.0006101636080.98545-100000@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Jun 2000, Kris Kennaway wrote:

> Recent compiler changes seem to have broken the ability to do 4.x
> buildworlds under -current - I've tested this on beast.freebsd.org and my
> own machines and got the same result. The build dies during the compiler
> phase with lots of stuff like:
> 
> /morden/usr3/tmp/obj//morden/usr3/tmp/src/i386/morden/usr3/tmp/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In
> function `finish_function':
> c-decl.o(.text+0x8360): multiple definition of `finish_function'
> decl.o(.text+0x10880): first defined here
> /usr/libexec/elf/ld: Warning: size of symbol `finish_function' changed
> from 3003 to 565 in c-decl.o
> ...

This is a bug in the cc Makefiles in 4.x.  It was fixed in -current in:

# RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_int/Makefile,v
# Working file: Makefile
# head: 1.26
# ...
# ----------------------------
# revision 1.26
# date: 2000/05/24 20:02:21;  author: obrien;  state: Exp;  lines: +2 -2
# Move c-decl.c out of the common libcc_int.a into the binary Makefiles
# where it is used.  c-decl has symbols that conflict with several of the
# cc1plus sources.
# 
# GNU `ld' was changed in Dec 1999 to be more be compatable with the way that
# other linkers work (specifically in the Solaris linker).  The 2.9.1 `ld',
# did the Wrong Thing in that if a library contained a common symbol that
# matched a definition of that symbol in another (already linked in object)
# it would also be linked in, even if there was no other reason to do so.
# This is wrong.  The library should only be linked in if it contains
# non-common, non-weak symbols which are needed by previously linked in
# objects.
# ----------------------------

etc.

This could be fixed by MFC to RELENG_4, but bootstrapping from 4.0, 3.x
and 2.x is much harder to fix.

Building old kernels under -current is becoming difficult.  I build kernels
for RELENG_3 and RELENG_4.  This causes a lot of new warnings about invalid
assembler, but still works, at least a week ago.  I left genassym(1) in
/usr/bin to avoid breaking the build of RELENG_4 kernels until the genassym
changes are MFC'ed.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006111630560.972-100000>