From owner-freebsd-hackers Wed Sep 11 13:10:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26600 for hackers-outgoing; Wed, 11 Sep 1996 13:10:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA26590 for ; Wed, 11 Sep 1996 13:10:49 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05436; Wed, 11 Sep 1996 13:09:43 -0700 From: Terry Lambert Message-Id: <199609112009.NAA05436@phaeton.artisoft.com> Subject: Re: shared libg++2.7.2 To: ajones@ctron.com (Alexander Seth Jones) Date: Wed, 11 Sep 1996 13:09:43 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <32371A09.451E@ctron.com> from "Alexander Seth Jones" at Sep 11, 96 03:59:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But, there seems to be another problem. When compiling exceptioni.cc > from the stdc++ lib, I get the following warning from the assembler: > > /var/tmp/cc000339.s: Assembler messages: > /var/tmp/cc000339.s:603: Warning: GOT relocation burb: > `___EXCEPTION_TABLE__' should be global > > and I then create the shared lib as above. But linking just a little > program that cout's "hi", core dumps in __register_exceptions before > main is called. I know the exception handling code is sketchy right > now, but ... IO believe it relies on use of weak symbols for the subclassing. Our assembler does not support weak symbols. One possible approach would be to install John Polstra's "ELFKit"; this presumes you are running -current, and so have an execution class loader for BSD ELF binaries. You would then use the newer binutils and avoid the problem. I don't know of another fix in the context of the current build tools. Alternately, there were a number of weak symbol fixes that went into 2.7.2.1 -- which is the release you should be running instead of 2.7.2; it is a set of patches against 2.7.2. They have been promising to integrate the patches with some other fixes and rerelease as 2.7.3 for about 3 months now; I would not hold my breath. > Any compiler gurus care to offer some insight? Is this a compiler > problem, an assembler problem, or has anyone actually gotten the libs > built shared and I'm doing something outlandishly dumb? > > I'd like to see if other people are running into this problem before I > report it to the GNU people. I don't know anyone who is successfully running the 2.7.2 code. You should check the GCC mailing lists, since I remember someone claiming to use them with a couple of patches on top of the 2.7.2.1 patches (sorry, I have no more information than that; I get the lists bridged, and I only read them occasionally to keep on top of things, so I don't save stuff off other than release announcements). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.