Date: Sat, 15 Jan 2000 17:21:29 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <20000115092129.7A7171C03@overcee.netplex.com.au> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> of "Sat, 15 Jan 2000 05:04:53 %2B1100." <Pine.BSF.4.10.10001150503040.7883-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Wed, 12 Jan 2000, John Polstra wrote: > > > Jason Evans <jasone@canonware.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000115092129.7A7171C03>