From owner-freebsd-hackers Mon Feb 12 04:25:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA25622 for hackers-outgoing; Mon, 12 Feb 1996 04:25:14 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA25604 for ; Mon, 12 Feb 1996 04:25:09 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id HAA16076 for hackers@freebsd.org; Mon, 12 Feb 1996 07:31:22 -0500 From: Peter Dufault Message-Id: <199602121231.HAA16076@hda.com> Subject: g++ 2.7.2 / libg++ 2.7.1 and ld To: hackers@freebsd.org Date: Mon, 12 Feb 1996 07:31:22 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk I've been down the dead end that apparently several others have in trying to get g++ 2.7.2 / libg++ 2.7.1 fully working on FreeBSD. I believe the final stumbling block is our linker. Quick summary: 1. Start with pgcc in -ports; 2. (Now you need -lstdc++) Use libg++-2.7.1 from prep; 3. (Now you need weak symbol support in assembler) Use "as" from binutils-2.6 4. (Now you need weak symbol support in linker?) Reach a dead end without work on ld. As suggested in the list archives, I tried adding "#define SUPPORTS_WEAK 0" to config/xm-freebsd.h in the compiler, however, it still generates weak symbols. The current problem is that the g++ compiler is generating weak symbols with colliding names that I assume the linker is supposed to uniquely resolve - at least that is my guess. For example, two separate .cc files are generating this symbol: > rt# ./foo > 0000086a ? ___15CG56XCSynchCommRC15CG56XCSynchComm > 00000832 ? ___15CG56XCSynchCommRC15CG56XCSynchComm and an examination of the associated .s shows it is weak. The distributed gnu binutils linker fall down on FreeBSD. If you configure it as any of our formerly close relatives (bsd, bsdi, or netbsd) it won't work: > rt# ./configure i386-unknown-bsd > rt# make all-ld (...) > rt# gcc -o foo foo.c > /usr/lib/crt0.o: file not recognized: File format not recognized If you configure it as just plain a.out it also falls down: > rt# ./configure i386-unknown-aout (...) > rt# gcc -o foo foo.c > ld:/usr/local/lib/gcc-lib/pentium-unknown-freebsd/2.7.2p/libgcc.a: file format not recognized; treating as linker script > ld:/usr/local/lib/gcc-lib/pentium-unknown-freebsd/2.7.2p/libgcc.a:1: parse error I'm surprised at this. I've promised to do the ptolemy pre release testing by Friday and I didn't think the biggest problem would be getting the tool chain up and running. I have to leave for a week this Friday and don't have time to chase down this linker issue as well as everything else I have to finish up. I will be endebted to whomever can get this tool chain working properly by about Wednesday. Please let me know if you can do it. I'm also interested in why we had to go off in left field with our linker. Is it something with our shared library support? Can I perhaps generate static only programs with the gnu tools? -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267