Hello TDragon.
I think I have found a bug. While I was working on a certain example from a book of mine, I have discovered a bug regards to istream_iterator.
The code I used is this:
// ioiter1.cpp
#include <iostream>
#include <vector>
#include <algorithm>
#include <string>
int main()
{
using namespace std; // all symbols in std are global
vector<string> coll; // vector container for strings
/* read strings from the standard input up until the end of the data
* - copy from the 'input collection' cin, inserting into coll
*/
copy(istream_iterator<string>(cin), // start of source range
istream_iterator<string>(), // end of source range
back_inserter(coll)); // destination range
// sort elements in coll
sort(coll.begin(), coll.end());
/* output all elements
* - copy from coll to the 'output collection' cout
* - every string on its own line (separated by "\n")
*/
copy(coll.begin(), coll.end(), // source range
ostream_iterator<string>(cout, "\n")); // destination range
}
A special thanks goes to Nicolai M. Josuttis, author of book Object-Oriented Programming in C++, for composing such an amazing book.
The error report by compiler is this:
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp||In function 'int main()': |
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|16|error: 'istream_iterator' was not declared in this scope|
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|16|error: expected primary-expression before '>' token|
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|17|error: expected primary-expression before '>' token|
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|17|error: expected primary-expression before ')' token|
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|28|error: 'ostream_iterator' was not declared in this scope|
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|28|error: expected primary-expression before '>' token|
C:\Projects\Josuttis_OOP\Chapter_03\17. IOiter1\ioiter1.cpp|28|warning: left-hand operand of comma has no effect|
||=== Build finished: 6 errors, 1 warnings ===|
I have pastebin-ed the current code and asked for help from Freenode's #C++-basic and tested it on Codepad (http://codepad.org) and compiled just fine.
Can you please test this code with your 4.5.0 version and provide me your feedback? That would be greatly appreciated.
I'm waiting for anyone's reply.
Regards,
stefanos_
Hmm... but I found a real bug too :)
This code snippet is supposed to work fine and indeed does work fine with gcc 4.4 as well as gcc 4.5 non-optimized.
However, it crashes in optimized build. #pragma GCC optimize ("-O0") immediately preceding the function prevents crash. It appears that the compiler wrongly "optimizes out" the variable sizeReq and uses nullptr as its memory address.
DynamicLibrary iphlpapi("iphlpapi.dll");
if(iphlpapi)
{
typedef DWORD (WINAPI *GetIfTable_t)(PMIB_IFTABLE,PULONG,BOOL);
GetIfTable_t GetIfTable_fun = iphlpapi.GetSymbol("GetIfTable");
if(!GetIfTable_fun) // be sure funcptr is valid
return;
PMIB_IFTABLE pInfo = 0;
DWORD sizeReq = 0;
// supplying a zero-size buffer returns ERROR_INSUFFICIENT_BUFFER
// and writes the required buffer size to sizeReq
GetIfTable_fun(0, &sizeReq, 0); // crashes writing to address 0x00000000, i.e. &sizeReq == nullptr
// now reserve the correct size
pInfo = (PMIB_IFTABLE) alloca(sizeReq);
// and finally, go for the real thing
if(GetIfTable_fun(pInfo, &sizeReq, 0) == NO_ERROR )
{
for(...)
...
Ok here some results of me trying to build wxWidgets on Windows 7 x64 (cmd line) :
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1
- wx 2.9-svn, mingw64-TDM, 64bit mode : Ok
- wx 2.8.10, mingw64-TDM, 32bit mode : Fails at link-time
- wx 2.8.10, mingw32-TDM, 32bit mode : Ok
The flags used were (here part of the config.gcc for the failed 2nd try):
# Standard flags for CC
CFLAGS ?= -pipe -march=core2 -m32 -floop-interchange -floop-strip-mine -floop-block
# Standard flags for C++
CXXFLAGS ?= -pipe -march=core2 -m32 -floop-interchange -floop-strip-mine -floop-block
# Standard preprocessor flags (common for CC and CXX)
CPPFLAGS ?=
# Standard linker flags
LDFLAGS ?= -Wl,--as-needed -m32
the -m32 switch was replaced by -m64 in the 1st try and by nothing in the 3rd.
Here the error message for the 2nd try:
[...]
g++ -shared -fPIC -o ..\..\lib\gcc_dll\wxmsw28u_gcc_custom.dll gcc_mswudll\monod
ll_dummy.o gcc_mswudll\monodll_version_rc.o gcc_mswudll\monodll_appbase.o gcc_ms
wudll\monodll_arcall.o gcc_mswudll\monodll_arcfind.o gcc_mswudll\monodll_archive.o [many more *.o files...]
Creating library file: ..\..\lib\gcc_dll\libwxmsw28u.a
c:/mingw64-tdm/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mi
ngw32/bin/ld.exe: i386:x86-64 architecture of input file `gcc_mswudll\monodll_ve
rsion_rc.o' is incompatible with i386 output
collect2: ld returned 1 exit status
mingw32-make: *** [..\..\lib\gcc_dll\wxmsw28u_gcc_custom.dll] Error 1
Any hints at what I might have missed there or why Mingw64 can't build correctly wxWidgets in 32 bit mode ?
edit: I tried again with only minimal flags (ie. no graphite, no march, no as-needed, no pipe) but it still fails in the same way...
The same happens when building the src target of codeblocks :
x86_64-w64-mingw32-g++.exe -Lbase\tinyxml -LD:\lib\wxWidgets-2.8.10\lib\gcc_dll -Ldevel -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\compilersettingsdlg.o .objs\src\crashhandler.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\environmentsettingsdlg.o .objs\src\infopane.o .objs\src\main.o .objs\src\notebookstyles.o .objs\src\printdlg.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o .objs\src\switcherdlg.o .objs\src\resources\resources.res -Wl,--enable-auto-import -mthreads -Wl,--as-needed -m32 -lcodeblocks -lwxscintilla -lwxpropgrid -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u -mwindows
c:/mingw64-tdm/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `.objs\src\resources\resources.res' is incompatible with i386 output
collect2: ld returned 1 exit status
I'm trying to build TDM-GCC 4.5.0 32 bits from the sources using the provided makefile and scripts. I think I correctly followed the instructions but I'm stuck somewhere (during the compilation of the ppl lib I think). It says:
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -frounding-math -O2 -I/cr
ossdev/support-stage-tdm32/gmp/include -W -Wall -version-info 8:0:1 -no-undefin
ed -s -L/crossdev/support-stage-tdm32/gmp/lib -o libppl.la -rpath /crossdev/supp
ort-stage-tdm32/ppl/lib Box.lo checked.lo Checked_Number.lo Float.lo fpu-ia32.lo
Constraint.lo Constraint_System.lo Congruence.lo Congruence_System.lo Generator
_System.lo Grid_Generator_System.lo Generator.lo Grid_Generator.lo Init.lo Coeff
icient.lo Linear_Expression.lo Linear_System.lo Matrix.lo Scalar_Products.lo MIP
_Problem.lo Poly_Con_Relation.lo Poly_Gen_Relation.lo BHRZ03_Certificate.lo H79_
Certificate.lo Grid_Certificate.lo Polyhedron_nonpublic.lo Polyhedron_public.lo
Polyhedron_chdims.lo Polyhedron_widenings.lo C_Polyhedron.lo NNC_Polyhedron.lo G
rid_nonpublic.lo Grid_public.lo Grid_chdims.lo Grid_widenings.lo BD_Shape.lo Oct
agonal_Shape.lo Pointset_Powerset.lo Row.lo Linear_Row.lo Bit_Matrix.lo Bit_Row.
lo Ph_Status.lo Grid_Status.lo Variable.lo Variables_Set.lo conversion.lo minimi
ze.lo simplify.lo Grid_conversion.lo Grid_simplify.lo stdiobuf.lo c_streambuf.lo
globals.lo mp_std_bits.lo version.lo wrap.lo -lm -lgmpxx -lgmp
/bin/grep: /mingw/lib/gcc/mingw32/4.5.0/libstdc++.la: No such file or directory
/bin/sed: can't read /mingw/lib/gcc/mingw32/4.5.0/libstdc++.la: No such file or
directory
libtool: link: `/mingw/lib/gcc/mingw32/4.5.0/libstdc++.la' is not a valid libtoo
l archive
make[4]: *** [libppl.la] Error 1
make[4]: Leaving directory `/crossdev/build/ppl-tdm32/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/crossdev/build/ppl-tdm32/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/crossdev/build/ppl-tdm32'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/crossdev/build/ppl-tdm32'
make: *** [ppl] Error 2
I see it can't find libstdc++.la but according to the building instructions (unless I didn't understand them correctly) provided in the TDM release, /mingw should be empty at this point. Then it's normal it can't find libstdc++.la in this path.
Any Idea?
Thanks
One more question... I'm trying to build wxWidgets 2.8.11 using the 64-bit binaries and I'm hitting a snag:
../../src/msw/thread.cpp: In static member function 'static THREAD_RETVAL wxThreadInternal::DoThreadStart(wxThread*)':
../../src/msw/thread.cpp:525:43: error: cast from 'void*' to 'THREAD_RETVAL' loses precision
../../src/msw/thread.cpp: In member function 'wxThreadError wxThreadInternal::WaitForTerminate(wxCriticalSection&, void**, wxThread*)':
../../src/msw/thread.cpp:845:21: error: cast from 'void*' to 'DWORD' loses precision
../../src/msw/thread.cpp: In member function 'void wxThread::Exit(void*)':
../../src/msw/thread.cpp:1165:28: error: cast from 'void*' to 'unsigned int' loses precision
make: *** [gcc_mswudll\monodll_thread.o] Error 1
I'm using the Code::Blocks build instructions:
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1
- using a different version of GCC, not TDM-GCC.
You were right about that:
gcc --version
gcc (GCC) 4.5.0
Copyright (C) 2010 Free Softwarre Foundation, Inc.
<License stuff>
I guess I messed things up during installation. Well, recompiling with the actual TDM-GCC will solve this, right?
I successfully installed TDM-GCC 4.5.1 but I get link errors:
obj\ZTimerManager.o:ZTimerManager.cpp:(.text+0xcd): undefined reference to `_Unwind_Resume'
obj\ZTimerManager.o:ZTimerManager.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0
I found some solutions like linking with libstdc++, someone mentioned that "__gxx part indicates that this is a g++-specific implementation issue. The .eh_frame probably indicates that it is concerned with exception handling, code for which may be automatically inserted for C++ programs. If so, you could disable exceptions with a compiler flag or link in the proper symbols from a library that came with your compiler (perhaps libstdc++?) " but none of these work.
Is there a flag or option I shoud add?
You can use boost.threads + something like:
namespace mine
{
#ifdef HAS_CPP_THREADS
using std::thread;
#else
using boost::thread;
#endif
}
Then in you code you use mine::thread and you have some flexibility. :lol: