From owner-freebsd-hackers Sat Apr 11 13:01:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA28450 for freebsd-hackers-outgoing; Sat, 11 Apr 1998 13:01:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-18.waterford.indigo.ie [194.125.139.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28443 for ; Sat, 11 Apr 1998 13:00:51 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id VAA06760; Sat, 11 Apr 1998 21:01:16 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804112001.VAA06760@indigo.ie> Date: Sat, 11 Apr 1998 21:01:16 +0000 In-Reply-To: John Polstra "Re: ld: internal error: allocated set symbol space (2) doesn't match actual (6)" (Apr 11, 10:17am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: John Polstra , rotel@indigo.ie Subject: Re: ld: internal error: allocated set symbol space (2) doesn't match actual (6) Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 11, 10:17am, John Polstra wrote: } Subject: Re: ld: internal error: allocated set symbol space (2) doesn't ma > > FWIW here is the diff of the output of nm for a -O2 main.o and a -03 > > main.o: > > Thanks. Could I trouble you to do the same thing using "ldd -v" > instead of "nm"? That gives a lot more useful information. Firstly a correction to my earlier post, I do not know if the problem occurs with gcc 2.7.2.1 for the simple reason that it cannot compile the code because it contains exception handling stuff that earlier gcc's don't grok too well. I thought I had been picking up /usr/bin/c++ with "c++" but just noticed that I wasn't. (doh) It does link ok egcs on other platforms though, so I still think its a bug with the linker. I've been working on isolating a simple test case that might be more useful than the output from ldd -v, (though you're still welcome to that, or the source/binaries) I've appended it to this mail. If you compile it with egcs-current without -DGLOBAL then all cases work, if you compile with -DGLOBAL then it won't link for cases A and D, it links but dumps core before main() for cases B and E and case C works fine. This code doesn't use exception handling so I've tried it with gcc 2.7.2.1 and it works in all cases. This kinda points the finger at egcs, so if you want me to take this to egcs-bugs thats ok :) However I would be surprised if egcs is at fault because this code is very, very simple and it would have to be extremely brain dead to get it wrong, which is the opposite of my experience with egcs. If you don't have egcs then I guess you can't compile this code and see it break, if so give me a shout for what you need (ldd -v, object files etc.) Regards, Niall #if defined(CASE_A) || defined(CASE_C) || defined(CASE_D) #include #endif #if defined(CASE_B) || defined(CASE_E) #include #endif class C { public: #if defined(CASE_A) C() { cout << 0 << endl; } #elif defined(CASE_B) C() { printf("%d\n", 0); } #elif defined(CASE_C) foo() { cout << 0 << endl; } #elif defined(CASE_D) ~C() { cout << 0 << endl; } #elif defined(CASE_E) ~C() { printf("%d\n", 0); } #else #error define one of CASE_[ABCDE] when compiling #endif }; #ifdef GLOBAL C c; #endif int main() { #ifndef GLOBAL C c; #endif #ifdef CASE_C c.foo(); #endif return 0; } -- Niall Smart. Microsoft Suck. See www.freebsd.org for details. Annoy your enemies and amaze your friends: echo "#define if(x) if(!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message