Hi,
> This was clearly an error but I can explain and fix it.
>
> There were overlapping main/gccmain (or so) functions in src/mingw and
> src/gcc-4.4.0/gcc/libgcc2.c . Both were calling constructors and
> destructors.
>
> Now, here's a debug session that shows that the constructor of the
> iost
On Fri, 2009-06-19 at 11:20 +0200, Johnny Willemsen wrote:
> > This was clearly an error but I can explain and fix it.
> >
> > There were overlapping main/gccmain (or so) functions in src/mingw and
> > src/gcc-4.4.0/gcc/libgcc2.c . Both were calling constructors and
> > destructors.
> >
> > Now,
I've figured out at least one way to get binutils to detect that iconv
is available on my system when compiling windres. In reading about
how autoconf works I found that the gcc code follows recommended
practice better than binutils does, and also noted that gcc tests for
HAVE_ICONV rather than HA
On Fri, 2009-06-19 at 17:02 +0200, Danny Backx wrote:
> I'm trying to track down the problem by writing small test programs that
> use C++ constructors in the presence of DLLs.
>
> I have something with a constructor in a DLL that doesn't look right,
> but I've not figured it out yet.
There's not
When I compile the same program with arm-mingw32ce-g++ or with
i386-mingw32ce-g++ , the results are different.
pavilion: {124} i386-mingw32ce-g++ -g -D_WIN32_IE=0x0400
-D_WIN32_WCE=0x0400 -o hello.exe hello.C
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
Info: resolving s