Date: Sun, 16 Jan 2000 05:10:18 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@netplex.com.au> Cc: John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <Pine.BSF.4.10.10001160421270.10098-100000@alphplex.bde.org> In-Reply-To: <20000115092129.7A7171C03@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Jan 2000, Peter Wemm wrote: > Bruce Evans wrote: > > ... and there is a linker > > bug that breaks elf static linkage (library functions can only be > > replaced by functions of the same size?). > No, that's not the problem. The problem is that libc.a has several But it is (was). It used to break static linkage of at least ctm_dequeue too, because ctm_dequeue has its own err() which needs to override the standard one. The problem has mysteriously vanished. It was present from approx. last August until recently. It still occurs if ctm_dequeue.c is broken by adding a call to one of the other functions in the library err.o conglomeration: # cc -O -pipe -Wall -I/usr/src/usr.sbin/ctm/ctm_dequeue/../ctm_rmail -static -o ctm_dequeue ctm_dequeue.o error.o # /usr/lib/libc.a(err.o): In function `err': # err.o(.text+0x30): multiple definition of `err' # error.o(.text+0x70): first defined here # /usr/libexec/elf/ld: Warning: size of symbol `err' changed from 232 to 30 in err.o # *** Error code 1 > 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. Indeed. At least cc/cc has this problem when it links to a private copy of mkstemps(), because it uses other functions in the library mktemp.o conglomeration. I thought that this had been fixed. Static linkage should work the same as shared linkage here. Since the library organisation is clearly broken, the bug must be in shared linkage :-). This problem is currently handled by putting a copy of the entire library mktemp.o (rebuilt from current sources) in a private library. It has to provide private versions for all the functions in the host mktemp.o that it uses. There is some potential for getting it wrong, because it needs to satisfy some of the functionality of the host mktemp.o but it uses the target sources. E.g., when we break up mktemp.c, the private library copy of mktemp.o will no longer contain mkstemps, and piecing together current sources to create an object enough like the old mktemp.o will be difficult. > 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 Not a solution for bootstrapping cc, since it will have no effect on linking cc to an old host library. Given that old libraries are broken, cc should consider that mkstemps() is library magic and use a different name for its version of of it. 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.10.10001160421270.10098-100000>