Some key point : Chris Sutcliffe wrote:
But the compiler complains of duplicate definitions of c++ functions in libstdc++_s.a and libstdc++.a. Did I miss something? I found the source of the issue, compiling using -O2 somehow links in libstdc++.a. Is there an equivalent optimization option to use the shared libstdc++_s.a? My memory is failing... we discussed this already: http://n2.nabble.com/Shared-libstdc%2B%2B-and--O2-produces-multiple-symbol-definition-error-td2167143.html adding -fno-inline fixes the problem (as was pointed out JonY in the above thread). Is this a bug or is there a reason for it? I'm not sure, but I'll look into it. Honestly, shared libstdc++-v3 has quite a few issues, and this will never really be right until someone takes the time to solve the underlying problems carefully and get it into FSF GCC. ---------------------------------------------------------------------------- Problem setting a breakpoint in a header file. Steps to demonstrate the problem: (1) Create and move to directory C:\CB (2) Create header file Function.h inline int Fcn1() { return 1; } (3) Create source file main.cpp #include "Function.h" int main() { int A = Fcn1(); A *= 2; return 0; } (4) Open a command window (5) Compile with following (note backslashes in filename as used by CodeBlocks in Windows) gcc -g C:\CB\main.cpp -o CB.exe (6) Launch debugger gdb CB.exe (7) Try to set breakpoint in header (gdb) b C:\CB\Function.h:3 and get error No source file named C:\CB\Function.h in loaded symbols. (8) Quit debugger, erase CB.exe and recompile with following (note forward slashes) gcc -g C:/CB/main.cpp -o CB.exe (9) Launch debugger gdb CB.exe (10) Again try to set breakpoint in header (gdb) b C:\CB\Function.h:3 and this time successfully get Breakpoint 1 at 0x4017db: file C:/CB/Function.h, line 3. --------------------------------------------------------- It seems using *forward slashes* can works quite well. but using back slashes will get the wrong result. ---------------------------------------------------------------------------- Massimo Gaspari wrote: > Platform : Windows XP Sp3 , MinGW latest binutils,make,runtime and GCC > 4.4.0 > > I used it to compile (./configure --disable-shared) GSL 1.12 And I'm > reporting that using CFLAGS = -fexception the checking completed > successfully. > > But using optimization (CFLAGS = -O2 -fexceptions) the testing fails at > (first error) > > make[2]: Leaving directory `/home/Massimo/gsl-1.12/integration' > make check-TESTS > make[2]: Entering directory `/home/Massimo/gsl-1.12/integration' > FAIL: qawc(f459) elist (1.8329242496630777e-015 observed vs > 1.8330829482071535e-015 expected) [744] > FAIL: test.exe > > I compiled the source code for GSL 1.12 successfully (well disregarding > the well known montecarlo optimizer bug) with GCC 3.4.5 and GCC 4.2.1. > So it seems a new bug of the new GCC compiler (optimizer) in MinGW. I > don't know if the same bug is also present in other platforms. I didn't > find any reports in the GCC sites about that bug. > > I also tested the TDM GCC 4.4.0 (R2) and GSL 1.12 and I got the same > failure using optimization. Thank you for reporting this. This is potentially a very serious issue. Can you try adding -ffloat-store to the CFLAGS and rebuilding from scratch to see if this helps? This often solves rounding issues such as these. I see one bug in GCC Bugzilla about the GSL testsuite, <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180>, but I do not think this is the same bug. I'm curious if this bug is Windows-specific, or if it occurs on Linux i386 also. ------------------------------------------------------------------------------ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
