From owner-freebsd-current Sat Jan 15 1:21:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9DCFF14E15 for ; Sat, 15 Jan 2000 01:21:31 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 7A7171C03; Sat, 15 Jan 2000 17:21:29 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Bruce Evans Cc: John Polstra , current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. In-Reply-To: Message from Bruce Evans of "Sat, 15 Jan 2000 05:04:53 +1100." Date: Sat, 15 Jan 2000 17:21:29 +0800 From: Peter Wemm Message-Id: <20000115092129.7A7171C03@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Wed, 12 Jan 2000, John Polstra wrote: > > > Jason Evans wrote: > > > > > 2) Make a separate copy of mktemp.c to remove the internal dependency. > > > > I think this is the best approach -- likewise for getobjformat.c, > > I agree. egcs provided "mkstemp.c" to handle the problem, but this > didn't work on Warner's system because he had mkstemps() in libc > (mkstemp.c actually implements mkstemps()) and there is a linker > bug that breaks elf static linkage (library functions can only be > replaced by functions of the same size?). The "fix" was to add > mkstemps() to the -current libc and not use the egcs version. Three > or four subsequent "fixes" led to the current evil one. gcc has > complicated things a little by moving mkstemp.c to a version of > libiberty which we don't have. Reaching out to the libiberty tree > is only slightly better than reaching out to the libc tree. > > Anyway, the main problem is yours to fix in ld :-). No, that's not the problem. The problem is that libc.a has several functions, including mktemp, mkstemp, tmpnam etc, all in the one .o file. gcc (g++ at least) uses mktemp() from that .o file in libc.a. That .o file also provides mkstemps on newer builds. Now, if you try and do this with a function that refers to mktemps: cc -o foo uses_mkstemps.o uses_mktemp.o -lmymkstemps -lc then you end up with mkstemps coming from the first library and then mktemp causing the mktemp+mkstemp+mkstemps+etc.o file to come from libc.a leading to a conflict... we have two mkstemps()'s in the file now and hence the problem. The solution is to break up all the multi-function files in libc as we should have done ages ago. Not only does this work out more efficient for static binaries, it also cuts down a good deal of symbol cross-reference explosions where some file is linked because of one of it's functions and then one of the other functions that came along with it (but is otherwise unused) then causes 20 other .o files to be pulled in to satisfy it's symbols. In dynamic linking mode this doesn't matter. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message