From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Yuen To: egcs-bugs@egcs.cygnus.com Cc: eep1py@ee.surrey.ac.uk (Peter Yuen) Subject: bug report Date: Fri, 16 Apr 1999 12:01:00 -0000 Message-id: X-SW-Source: 1999-04/msg00459.html List-Id: Dear Sir I would like to report an internal compiler error. Information can be found as follows: (1) The egcs version is GNU C++ version egcs-2.91.60 (2) The system type is Ultrasparc-sun-solaris2.5.1 (3) set VTKPATH = /vol/vssp/3D-data/vtk/vtk2.0-ogl-cc/vtk20p1 /opt/GNUdevelop/bin/g++ -v --save-temps -c -DGNU -D__sol2__ -Dunix -DNEWGCC -D_REENTRANT -Wall -pipe -DAMMA_CHECK -ansi -I. -I$VTKPATH/common -I$VTKPATH/graphics -I$VTKPATH/imaging -DUSE_OGLR -D_HP_NO_FAST_MACROS -I/vol/vssp/local/amma/inc/sol2 -I/vol/vssp/local/amma/inc -o objs/$1.o $1.cc (4) Preprocessed output of the source file that caused the compiler error is put at http://www.ee.surrey.ac.uk/Personal/P.Yuen/bugreport/ Thank you very much. Yours faithfully Peter Yuen Ps Source, error messages and compile options can also be found at above web page. >>From chris@ludwig-alpha.unil.ch Fri Apr 16 13:27:00 1999 From: Christian Iseli To: law@cygnus.com Cc: egcs-bugs@egcs.cygnus.com Subject: Re: egcs-ss-19990228, alpha-linux, ICE in glibc-2.1 Date: Fri, 16 Apr 1999 13:27:00 -0000 Message-id: <199904162027.WAA17429@ludwig-alpha.unil.ch> References: <20508.923654476@upchuck> X-SW-Source: 1999-04/msg00460.html Content-length: 960 Hi, Jeff Law said: > In message <199903031420.PAA23155@ludwig-alpha.unil.ch>you write: > > While trying to compile glibc-2.1 using the latest snapshot: > > > > Reading specs from /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.93.10/specs= > > > > gcc version egcs-2.93.10 19990228 (gcc2 ss-980929 experimental) > > > > cc1 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings > > -funroll-loops -mieee -fPIC nsswitch.i > > > > gets a segfault. > > > > System: > > Linux version 2.2.2-ac7 (root@ludwig-alpha.unil.ch) > > (gcc version egcs-2.91.62 19990224 (egcs-1.1.2 pre-release-2)) #2 > > Tue Mar 2 17:58:48 CET 1999 > > I use glibc-2.1. > > > > I'm attaching the pre-processed input. > ... ] >Thanks. I just tried this with the current sources and it seems to be >fine now. I just tried here with 19990412. Still doesn't work with -O2, but seems fine with -O. -fPIC does not seem to make a difference. Did you also try with -O2 ? Christian >>From pasquini@cs.purdue.edu Fri Apr 16 13:52:00 1999 From: Reuben Pasquini To: egcs-bugs@cygnus.com Subject: bug in egcs-g++-1.0.2-12 Date: Fri, 16 Apr 1999 13:52:00 -0000 Message-id: <3717A7F8.BE8C87D9@cs.purdue.edu> X-SW-Source: 1999-04/msg00461.html Content-length: 4039 Hello, I've come across a bug in egcs-g++-1.0.2-12 on my RedHat 5.1 Linux system. The problem results when I try to instantiate an object of a class that overides the new operator and is a subtype of two classes (multiple inheritance) that also both overide new. I get the following error: pasquini@joanne 9 tests/PCS/bin % make LP_thread.o g++ -g -gstabs+ `guile-config compile` -fPIC -D_REENTRANT -I/home/pasquini/research/parasol/kernel/src -I/home/pasquini/research/parasol/kernel/src/base -I/home/pasquini/research/parasol/kernel/src/calendar -I/home/pasquini/research/parasol/kernel/src/communication -I/home/pasquini/research/parasol/kernel/src/driver -I/home/pasquini/research/parasol/kernel/src/messages -I/home/pasquini/research/parasol/kernel/src/runtime_stats -I/home/pasquini/research/parasol/kernel/src/state -I/home/pasquini/research/parasol/kernel/src/threads -I/home/pasquini/research/parasol/kernel/src/virtual_time -I/home/pasquini/research/parasol/kernel/include -I/home/pasquini/research/parasol/domains/common/include -I/home/pasquini/research/parasol/domains/common/src -I../src -I/usr/local/include/gc -I/usr/local/include -c -o LP_thread.o ../src/LP_thread.cpp ../src/LP_thread.cpp: In method `void LP_thread::run()': ../src/LP_thread.cpp:62: Internal compiler error. ../src/LP_thread.cpp:62: Please submit a full bug report to `egcs-bugs@cygnus.com'. Line 62 is: op_mesh = new (MapNoGC) PCS_mesh ( i_mesh_dimension, op_rng ); I've attatched the code for LP_thread.cpp, PCS_mesh.hxx, and PCS_mesh's two supertypes - Batch and State. The Solaris CC compiler is able to handle this code, so I assume it's correct. Thanks for your work on egcs, and good luck. Reuben -- ------------------------------------------------------------------------- Reuben Pasquini pasquini@cs.purdue.edu Department of Computer Science www.cs.purdue.edu/people/pasquini Purdue University Fax: 1-765-494-0739 West Lafayette, IN 47907-1398 Office: 765-494-0361 ------------------------------------------------------------------------- /** * LP_thread.cpp: LP_thread for the PCS simulation * * @author Reuben Pasquini * @log * 04/14/1999 - created from torus/LP_thread */ #include #include #include // for getenv #include #include #include "LP_thread.hxx" #include "PCS_mesh.hxx" #include "PCS_cell.hxx" #include "Debug.hxx" #include "Work_thread.hxx" #include "Random.hxx" extern "C" { #include #include }; extern Kernel * gp_kernel; /** * LP_thread::LP_thread (): constructor does nothing since the * ParaSol kernel hasn't been initialized yet. * Initialization at the beginning of ::run () * * @log * 04/14/1999 - created */ LP_thread::LP_thread () { op_rng = 0; op_mesh = 0; } /** * LP_thread::run: this is the work routine which actually creates * the global objects and launches the initial threads * * @log * 09/05/1997 - created */ void LP_thread::run () { { char s_dirname[ 80 ]; sprintf ( s_dirname, "/homes/pasquini/tmp/core%d", gp_kernel->ProcId () ); chdir ( s_dirname ); } int i_mesh_dimension = (int)( gh_scm2long(gh_eval_str ( "mesh_dimension" )) ); assert ( i_mesh_dimension > 1 ); gp_kernel->debug ( DEB_APP, 0.0 ) << "Allocating rng & mesh" << endl; op_rng = new (MapNoGC) Random (); op_mesh = new (MapNoGC) PCS_mesh ( i_mesh_dimension, op_rng ); // Now let's create some threads that just make work for ( Iterator* p_iterator = op_mesh->iterator (); p_iterator->hasNext (); ) { PCS_cell* p_cell = (PCS_cell*)( p_iterator->next () ); if ( p_cell->ProcId () == gp_kernel->ProcId () ) { // it's a local cell Thread* p_workmaster = new (GC) Work_thread ( op_rng, p_cell, op_mesh ); p_workmaster->bootstrap (); } } hold_till_end (); gp_kernel->debug ( DEB_APP, gp_kernel->Time () ) << "Master thread running for last time!" << endl; } >>From la@iki.fi Fri Apr 16 14:40:00 1999 From: Lauri Alanko To: egcs-bugs@egcs.cygnus.com Subject: Funky templates in namespaces crash g++ Date: Fri, 16 Apr 1999 14:40:00 -0000 Message-id: <19990417003643.B13918@iki.fi> X-SW-Source: 1999-04/msg00462.html Content-length: 1457 Hello, there. Problem: Trying to compile this code with NAMESPACE defined causes an internal compiler error. When the template is outside namespaces, it works all right. Full error message: g++ -DNAMESPACE -Wall -W -Winline -ansi -pedantic -save-temps -c t.C -o t.o t.C: In instantiation of `Check': t.C:25: instantiated from `::N::::N::Check' t.C:25: instantiated from here t.C:25: Internal compiler error. t.C:25: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'. t.C:25: See for details. The code in question (a pretty minimal example): #ifdef NAMESPACE namespace N { #endif template class Check { struct Big { int x[2]; static Big f(void *) {return Big ();} static char f (Base*) {return 1;} }; public: enum{isA = (sizeof(Big::f(static_cast(0))) == 1)}; }; #ifdef NAMESPACE } using namespace N; #endif class X; template ::isA> class RP; RP * q; Compiler version: $ g++ -v Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) System: Linux/i386 2.2.5-ac4, glibc 2.1.1 WTF is that template supposed to do: See http://lazy.ton.tut.fi/~esap/instructive/simulating-constrained-genericity.html I hope this information is sufficient. Please try to get this fixed. Thanks, Lauri Alanko la@iki.fi >>From geoffk@ozemail.com.au Fri Apr 16 15:13:00 1999 From: Geoff Keating To: dje@watson.ibm.com Cc: Franz.Sirl-kernel@lauterbach.com, law@cygnus.com, jensting@imaginet.fr, mklinux-development-system@public.lists.apple.com, egcs-bugs@egcs.cygnus.com Subject: Re: EGCS-1.1.2 compile error on -O3 Date: Fri, 16 Apr 1999 15:13:00 -0000 Message-id: <199904161159.VAA00640@geoffk.wattle.id.au> References: <9904151721.AA53226@marc.watson.ibm.com> <9904151721.AA53226@marc.watson.ibm.com> X-SW-Source: 1999-04/msg00463.html Content-length: 11170 > Cc: Jens Tingleff , > mklinux-development-system@public.lists.apple.com, > egcs-bugs@egcs.cygnus.com > Date: Thu, 15 Apr 1999 13:21:29 -0400 > From: David Edelsohn > > SDFMotionCmpInv.pl:168: internal error--unrecognizable insn: > (insn 237 218 212 (set (reg:SI 9 r9) > (unspec[ > (symbol_ref/u:SI ("*.LC26")) > (reg:SI 65 lr) > ] 8)) -1 (nil) > (nil)) > > This is complaining because the register in the "unspec" is the link > register instead of a GPR. Whether reload should be able to handle this, > again, is a separate matter. I think that this is occurring because the > movsi_got pattern predicate is wrong. > > The pattern looks like: > > (define_expand "movsi_got" > [(set (match_operand:SI 0 "gpc_reg_operand" "") > (unspec [(match_operand:SI 1 "got_operand" "") > (match_dup 2)] 8))] > "(DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_SOLARIS) && flag_pic == 1" > " > { > if (GET_CODE (operands[1]) == CONST) > { > rtx offset = const0_rtx; > HOST_WIDE_INT value; > > operands[1] = eliminate_constant_term (XEXP (operands[1], 0), &offset); > value = INTVAL (offset); > if (value != 0) > { > rtx tmp = (no_new_pseudos ? operands[0] : gen_reg_rtx (Pmode)); > emit_insn (gen_movsi_got (tmp, operands[1])); > emit_insn (gen_addsi3 (operands[0], tmp, offset)); > DONE; > } > } > > operands[2] = rs6000_got_register (operands[1]); > }") > > Note that operands[2] is (match_dup 2) in the template but > operands[2] is not always assigned (because of the "DONE"), which I think > is the problem. > > The later helper define_insn pattern only can handle GPRs or MEM > for operands[2]. If it weren't for the sometimes assignment of > operands[2], I would use: > > (define_expand "movsi_got" > [(set (match_operand:SI 0 "gpc_reg_operand" "") > (unspec [(match_operand:SI 1 "got_operand" "") > (match_operand:SI 2 "reg_or_mem_operand" "")] 8))] > > I do not understand the intent of this pattern well enough to fix it, but > I think that operands[2] needs to be restricted in the registers that can > percolate through the define_expand pattern. > > I think this needs some attention from others more skilled in this > logic. This is a known problem. The fundamental problem is that rs6000_got_register is not safe to call during or after reload, because it allocates pseudo-registers and creates new users of registers. The purpose of the > operands[2] = rs6000_got_register (operands[1]); line is to initialise operands[2] in a call to gen_movsi_got; notice that gen_movsi_got only has two parameters. In the case where the DONE is hit, this pattern does not generate any RTL (it is done by the recursive calls to gen_movsi_got and gen_addsi3); otherwise, this pattern generates a single piece of RTL which is specified by its template. All this is documented in the gcc Info manual. The reason for the conditional is to avoid putting label+constant sums in the GOT; instead, the value of 'label' is extracted from the GOT and then 'constant' is added at runtime (I think this is also done for the TOC when generating XCOFF if you use the right switches). The '== CONST' test works because a label by itself is just (symbol_ref "foo") but a sum is (const (add (symbol_ref "foo") (const_int 42))) to compute foo+42. It couldn't hurt to add a comment saying /* Avoid putting label+constant entries in the GOT. */ just before the conditional... It's not like the rs6000.md file is exactly self-documenting :-). Remember, this is a define_expand, so (well, at least according to the docs), it is only used when called explicitly by gen_movsi_got. In fact, it is used from exactly one place, the "movsi" expander. The problem is that "movsi" operations can be generated during/after reload under some circumstances (in fact the whole point of reload is to move things around). The effect of this problem can range from nothing, through the 'unrecognizable insn' message quoted, to silently generating bad code. If I'm right, you can apply the patch below to fix it, but this is a horrible hack which works by suppressing parts of reload. I've previously posted it to egcs-patches; perhaps it should be included in the distribution? It's really really ugly, though. The patch probably needs updating to use the new variable, whose name I forget but which means 'too late to allocate new pseudo', instead of 'reload_in_progress || reload_completed'. I have a collection of examples that trigger this bug. I think some of them are in the egcs test suite. Suggestions on how to properly fix this problem would be _very_ welcome. The best solution I've thought of is that if reload could be taught how to deal with new uses of pseudo-registers appearing during reload, then this problem would go away. I think the appropriate response to the sudden appearance of a new register use is to reverse register allocation, turning some registers (only of the class of the newly used register, and maybe not even all of those) back to pseudo registers, and then going forward again, redoing register allocation (even local-alloc). This would be even more hairy than it sounds, but it would work and it would be reasonably efficient. -- Geoffrey Keating ===File ~/patches/egcs-3b.diff============================== 1998-11-26 Geoff Keating These patches collectively prevent reload from creating a new symbol_ref under powerpc -fpic, since it can't do it safely at present. * reload.c (AVOID_NEW_SYMBOL_REF): Define default. (find_reloads): When AVOID_NEW_SYMBOL_REF, don't call force_const_mem. * reload1.c (reload): Ignore (REG_EQUIV reg X) when NON_RELOAD_CONSTANT_P(X). * config/rs6000/rs6000.c (rs6000_got_register): Be safe. If the generated code might be invalid, abort() rather than silently generate bogus code. * rs6000.h (PREFERRED_RELOAD_CLASS): Get it right. This is needed so the other changes don't cause reload to fail. (AVOID_NEW_SYMBOL_REF): Define when -fpic. (NON_RELOAD_CONSTANT_P): When -fpic, constants that contain symbol_ref are unsafe for reload. --- gcc/reload.c.geoffk3 Sun Aug 16 10:54:51 1998 +++ gcc/reload.c Sun Sep 6 12:48:24 1998 @@ -113,6 +113,10 @@ a register with any other reload. */ #ifndef REG_MODE_OK_FOR_BASE_P #define REG_MODE_OK_FOR_BASE_P(REGNO, MODE) REG_OK_FOR_BASE_P (REGNO) #endif + +#ifndef AVOID_NEW_SYMBOL_REF +#define AVOID_NEW_SYMBOL_REF(X) 0 +#endif /* The variables set up by `find_reloads' are: @@ -2995,7 +2999,8 @@ find_reloads (insn, replace, ind_levels, win = 1; if (CONSTANT_P (operand) /* force_const_mem does not accept HIGH. */ - && GET_CODE (operand) != HIGH) + && GET_CODE (operand) != HIGH + && !AVOID_NEW_SYMBOL_REF (operand)) badop = 0; constmemok = 1; break; @@ -3071,7 +3076,9 @@ find_reloads (insn, replace, ind_levels, || (reg_equiv_address[REGNO (operand)] != 0)))) win = 1; /* force_const_mem does not accept HIGH. */ - if ((CONSTANT_P (operand) && GET_CODE (operand) != HIGH) + if ((CONSTANT_P (operand) + && GET_CODE (operand) != HIGH + && !AVOID_NEW_SYMBOL_REF (operand)) || GET_CODE (operand) == MEM) badop = 0; constmemok = 1; @@ -3248,6 +3255,7 @@ find_reloads (insn, replace, ind_levels, if (CONSTANT_P (operand) /* force_const_mem does not accept HIGH. */ && GET_CODE (operand) != HIGH + && !AVOID_NEW_SYMBOL_REF (operand) && ((PREFERRED_RELOAD_CLASS (operand, (enum reg_class) this_alternative[i]) == NO_REGS) @@ -3264,7 +3272,7 @@ find_reloads (insn, replace, ind_levels, LIMIT_RELOAD_RELOAD_CLASS, but we don't check that here. */ - if (! CONSTANT_P (operand) + if ((! CONSTANT_P (operand) || AVOID_NEW_SYMBOL_REF (operand)) && (enum reg_class) this_alternative[i] != NO_REGS && (PREFERRED_RELOAD_CLASS (operand, (enum reg_class) this_alternative[i]) @@ -3611,6 +3619,7 @@ find_reloads (insn, replace, ind_levels, && CONSTANT_P (recog_operand[i]) /* force_const_mem does not accept HIGH. */ && GET_CODE (recog_operand[i]) != HIGH + && !AVOID_NEW_SYMBOL_REF (operand) && ((PREFERRED_RELOAD_CLASS (recog_operand[i], (enum reg_class) goal_alternative[i]) == NO_REGS) --- gcc/reload1.c.geoffk3 Fri Aug 28 08:48:14 1998 +++ gcc/reload1.c Tue Sep 8 00:08:40 1998 @@ -675,7 +675,11 @@ reload (first, global, dumpfile) reg_equiv_memory_loc[i] = x; } - else if (CONSTANT_P (x)) + else if (CONSTANT_P (x) +#ifdef NON_RELOAD_CONSTANT_P + && !NON_RELOAD_CONSTANT_P(x) +#endif + ) { if (LEGITIMATE_CONSTANT_P (x)) reg_equiv_constant[i] = x; --- gcc/config/rs6000/rs6000.c.geoffk3 Wed Aug 26 04:48:18 1998 +++ gcc/config/rs6000/rs6000.c Sun Sep 6 12:48:24 1998 @@ -2279,11 +2279,11 @@ struct rtx_def * rs6000_got_register (value) rtx value; { + if (reload_in_progress || reload_completed) + abort(); + if (!current_function_uses_pic_offset_table || !pic_offset_table_rtx) { - if (reload_in_progress || reload_completed) - fatal_insn ("internal error -- needed new GOT register during reload phase to load:", value); - current_function_uses_pic_offset_table = 1; pic_offset_table_rtx = gen_rtx_REG (Pmode, GOT_TOC_REGNUM); } --- gcc/config/rs6000/rs6000.h.geoffk3 Wed Aug 26 04:48:20 1998 +++ gcc/config/rs6000/rs6000.h Mon Nov 23 21:20:18 1998 @@ -1105,8 +1105,11 @@ floating-point CONST_DOUBLE to force it to be copied to memory. */ #define PREFERRED_RELOAD_CLASS(X,CLASS) \ - ((GET_CODE (X) == CONST_DOUBLE \ - && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \ + (CONSTANT_P (X) \ + && ((CLASS) == FLOAT_REGS \ + || (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ + && (HOST_FLOAT_FORMAT != IEEE_FLOAT_FORMAT \ + || HOST_BITS_PER_INT != BITS_PER_WORD))) \ ? NO_REGS : (CLASS)) /* Return the register class of a scratch register needed to copy IN into @@ -1121,6 +1124,21 @@ #define SECONDARY_MEMORY_NEEDED(CLASS1,CLASS2,MODE) \ ((CLASS1) != (CLASS2) && ((CLASS1) == FLOAT_REGS || (CLASS2) == FLOAT_REGS)) + +/* There are some times when it is inconvenient to generate a new + symbol_ref. */ + +#define AVOID_NEW_SYMBOL_REF(X) (TARGET_ELF && flag_pic == 1) +#define NON_RELOAD_CONSTANT_P(X) \ + (AVOID_NEW_SYMBOL_REF(X) \ + && (GET_CODE (X) == SYMBOL_REF \ + || (GET_CODE (X) == CONST \ + && GET_CODE (XEXP (X, 0)) == PLUS \ + && GET_CODE (XEXP (XEXP (X, 0), 0)) == SYMBOL_REF) \ + || (GET_CODE (X) == CONST_DOUBLE \ + && GET_CODE (XEXP (X, 0)) == MEM \ + && GET_CODE (XEXP (XEXP (X, 0), 0)) == SYMBOL_REF))) + /* Return the maximum number of consecutive registers needed to represent mode MODE in a register of class CLASS. ============================================================ >>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 16 15:53:00 1999 From: "Martin v. Loewis" To: pere@hungry.com Cc: egcs-bugs@egcs.cygnus.com Subject: Re: C++ bug in EGCS v1.1.2 (accepting incorrect code) Date: Fri, 16 Apr 1999 15:53:00 -0000 Message-id: <199904162247.AAA00747@mira.isdn.cs.tu-berlin.de> References: <199904161448.QAA24965@lee.Cc.Uit.No> <199904161448.QAA24965@lee.Cc.Uit.No> X-SW-Source: 1999-04/msg00464.html Content-length: 910 > #include > > int > main() > { > > cout << "hello world" << endl; > } Yes, it accepts it although it shouldn't. > #include > > using std :: cout; > > int > main() > { > cout << "hello world" << endl; > } It should accept it, and it does. Also #include int main() { std::cout << "hello world" << std::endl; } should be accepted, and it is. > When will namespaces be fully supported? Namespaces are fully supported. The problem is that the C++ library is not correctly put into namespace std, yet; there is no date known when this will happen (see libstdc++-v3 page for details). To work around the current library limitation, egcs treats std in a special way. You can use -fhonor-std to switch-off this special-casing (see documentation for details), but then the library stops working. Hope this clarifies it, Martin >>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 16 16:17:00 1999 From: "Martin v. Loewis" To: eep1py@ee.surrey.ac.uk Cc: egcs-bugs@egcs.cygnus.com, eep1py@ee.surrey.ac.uk Subject: Re: bug report Date: Fri, 16 Apr 1999 16:17:00 -0000 Message-id: <199904162311.BAA00808@mira.isdn.cs.tu-berlin.de> References: X-SW-Source: 1999-04/msg00465.html Content-length: 886 > I would like to report an internal compiler error. Information can be > found as follows: Thanks for your bug report. I've tried compiling this with egcs-2.93.18 on sparc-sun-solaris2.5.1, and I get GcRecogn.cc: In function `IntT GcApplic(void *)': GcRecogn.cc:1626: invalid declarator GcRecogn.cc:1628: invalid declarator GcRecogn.cc:1630: invalid declarator GcRecogn.cc:1632: invalid declarator GcRecogn.cc:1676: `smallestTurnPt' undeclared (first use this function) GcRecogn.cc:1676: (Each undeclared identifier is reported only once GcRecogn.cc:1676: for each function it appears in.) GcRecogn.cc: In function `IntT GcRecogn(int, char **)': GcRecogn.cc:2009: warning: converting NULL to non-pointer type At least the last error seems to be correct, so I guess the bug has been fixed. Feel free to try a snapshot now or wait for release of 1.2 later this year. Regards, Martin >>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 16 16:23:00 1999 From: "Martin v. Loewis" To: craig@msmri.medicine.ubc.ca Cc: egcs-bugs@egcs.cygnus.com Subject: Re: String STL - current version? Date: Fri, 16 Apr 1999 16:23:00 -0000 Message-id: <199904162316.BAA00828@mira.isdn.cs.tu-berlin.de> References: <371757F0.3BF68AD4@msmri.medicine.ubc.ca> <371757F0.3BF68AD4@msmri.medicine.ubc.ca> X-SW-Source: 1999-04/msg00466.html Content-length: 651 > Is there any version of libstdc++ that libstdc++ that will allow a > simple program to compile? This looks like an installation problem to me. Please make sure that the header files and the library used both belong to the same compiler version, preferably to egcs 2.91.57 in your case. To do so, compile that program with '-v --trace-includes -Wl,--verbose', and see whether it is using the right directories all the time. In case you don't remember what the 'right directories' are, you might consider re-installing the compiler. If you do so, delete libstdc++.so and libstdc++.a first. In particular, the .so link looks wrong. Regards, Martin