From owner-freebsd-questions Thu May 6 13:39:52 1999 Delivered-To: freebsd-questions@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id ED98615252 for ; Thu, 6 May 1999 13:39:36 -0700 (PDT) (envelope-from marko@uk.radan.com) Received: from [158.152.75.22] (helo=uk.radan.com) by tele-post-20.mail.demon.net with smtp (Exim 2.12 #2) id 10fUvY-000OcP-0K; Thu, 6 May 1999 20:39:29 +0000 Organisation: Radan Computational Ltd., Bath, UK. Phone: +44-1225-320320 Fax: +44-1225-320311 Received: from marder-1. (rasnt-1 [193.114.228.211]) by uk.radan.com (8.6.10/8.6.10) with ESMTP id VAA01095; Thu, 6 May 1999 21:38:55 +0100 Received: (from marko@localhost) by marder-1. (8.9.2/8.8.8) id VAA00731; Thu, 6 May 1999 21:36:53 +0100 (BST) (envelope-from marko) Date: Thu, 6 May 1999 21:36:53 +0100 From: Mark Ovens To: Doug White Cc: FreeBSD-questions Subject: Re: gcc differences between aout & ELF Message-ID: <19990506213653.B255@marder-1> References: <19990505235002.C2189@marder-1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Doug White on Thu, May 06, 1999 at 10:59:37AM -0700 Organization: Total lack of Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 06, 1999 at 10:59:37AM -0700, Doug White wrote: > On Wed, 5 May 1999, Mark Ovens wrote: > > > On Wed, May 05, 1999 at 02:15:41PM -0700, Doug White wrote: > > > > > > Why don't you rebuild the required libraries to ELF? > > > > Why should I have too? This system was installed from scratch, it's > > all ELF (I've file(1)'d all the libs I can find and they're all > > ELF, except the aout compat stuff). > > Because you can't link aout libs into an elf binary. > Thanks for all the help. However you're beginning to confuse me ;-) I realize that you can't link aout libs into an elf binary, but I have ELF *and* aout versions ('cos I installed the compat22 dist): marder-1:/{58}% file /usr/lib/libm.so.2 /usr/lib/libm.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped marder-1:/{59}% file /usr/lib/compat/aout/libm.so.2.0 /usr/lib/compat/aout/libm.so.2.0: FreeBSD/i386 compact demand paged shared library not stripped So why rebuild them as ELF when ELF versions already exist? The libs created by for my program *are* being rebuilt and are ELF: > > I think I may know what I've screwed up. Before I installed gcc-2.8.1 > > I tried egcs-1.1.1. That gave more errors, so I then installed > > gcc-2.8.1. I've since read some docs at Cygnus' website that mention > > that egcs includes a new libstdc++ (?) whereas gcc-2.8.1 doesn't. > > Also pkg_info -v egcs-1.1.1 mentioned something about moving some > > libs "to avoid conflict with the stock compiler". I've pkg_deleted > > both egcs and gcc and the re-installed gcc. I'm now re-compiling > > my job (it'll take about 1-1/4 hours to compile the ~6000 source > > files) so I'm keeping my fingers crossed that it'll work this time. > > Yeah, stdc++ will muck things up badly. They're still playing with it on > -CURRENT. > :-( Having looked more closely at the output I realize that it's the linker that is erroring, not the compiler (I mistakenly thought that the compiler and linker were a matched pair, i.e. gcc-2.8.1 came with it's own linker, - not so) The problem is that symbols defined in libstdc++ are being redefined in libgcc. This is the sort of output I'm getting (the linker is run from a script, not a Makefile): linking PCOMPILE for OPL/autopcc /usr/local/lib/gcc-lib/i386-unknown-freebsd3.0/2.8.1/libgcc.a(exception.o): In function `bad_cast type_info function': /tmp/usr/ports/lang/gcc28/work/gcc-2.8.1/./cp/exception.cc(.text+0x0): multiple definition of `terminate(void)' /usr/lib/libstdc++.a(exceptioni.o)(.text+0x128): first defined here /usr/libexec/elf/ld: Warning: size of symbol `terminate__Fv' changed from 65 to 12 in exception.o and: /usr/marko/libopt/libutc.a(utc_string.o): In function `UTC_String::operator<<(short const &)': utc_string.o(.text+0x13d5): undefined reference to `ios virtual table' utc_string.o(.text+0x1427): undefined reference to `ostream::ios virtual table' utc_string.o(.text+0x1431): undefined reference to `ostrstream::ios virtual table' libutc.a is an archive built during the compile process. Does any of the above tell you anything? and, more importantly, can you suggest a fix? > Doug White > Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve > http://gladstone.uoregon.edu/~dwhite | www.freebsd.org > > -- FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://www.users.globalnet.co.uk/~markov _______________________________________________________________ Mark Ovens, CNC Apps Engineer, Radan Computational Ltd. Bath UK CAD/CAM solutions for Sheetmetal Working Industry mailto:marko@uk.radan.com http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message