MinGW - Minimalist GNU for Windows

To MinGW and Qt Folks -

On Mon, Apr 19, 2010 at 12:37 PM, Cesar Strauss <cestrauss@...> wrote:
> Dear MinGW community,
>
> I am pleased to announce the MinGW.org release of GCC 4.5.0.

Thanks!  MinGW (and GCC) is good stuff.

Would it make sense for me to upgrade from the tdm 4.4.1 build to the
official MinGW 4.5.0 build?

Right now I am doing some non-production, "experimental" programming,
focused primarily on playing around with Qt, which is new to me.

(I am also using Qwt and lp_solve in my test project, so if you happen to
know about those packages, please comment on compatibility, but I haven't
cross-posted to those lists, as two lists is probably more than enough...)

Has anyone used the new MinGW release with Qt?  Any gotcha's?

Aside from rebuilding Qt (go out get a cup of coffee -- no, actually a pot of
coffee -- oh heck, might as well go out and watch a movie marathon...), is
there anything I would have to do to upgrade to the official 4.5.0 build?

(I am using 32-bit MinGW on 64-bit windows 7.)

Thanks.


K. Frank


> GCC is the GNU Compiler Collection, a fairly portable optimizing
> compiler.
> ...

On Mon, Apr 19, 2010 at 01:37:26PM -0300, Cesar Strauss wrote:
> Dear MinGW community,
> 
> I am pleased to announce the MinGW.org release of GCC 4.5.0.
>
> General Notes:
> --------------
> 
> * Shared libgcc: If all modules are linked with -shared-libgcc,
>    exceptions can be thrown across DLL boundaries.  Note that this is
>    the default for all languages other than C. To disable this, use
>    -static-libgcc.
> 
> Known Issues:
> -------------

It is probably in your best interest to warn users either in
General Notes or Known Issues that exceptions in C++ do not work
in multithreaded programs, or, has this been resolved?

Thanks,
Bob Rossi

On 4/19/2010 11:29 AM, Bob Rossi wrote:
> On Mon, Apr 19, 2010 at 01:37:26PM -0300, Cesar Strauss wrote:
>    
>> Dear MinGW community,
>>
>> I am pleased to announce the MinGW.org release of GCC 4.5.0.
>>      
*snip*
> It is probably in your best interest to warn users either in
> General Notes or Known Issues that exceptions in C++ do not work
> in multithreaded programs, or, has this been resolved?
>    

Everything works fine in my multithreaded exceptions testcase (as long 
as, per the notes, -Wl,--enable-auto-import is used, but that's not 
related).

-John E.

On Mon, Apr 19, 2010 at 12:45 PM, John E. / TDM <tdragon@...> wrote:
> On 4/19/2010 11:29 AM, Bob Rossi wrote:
>> On Mon, Apr 19, 2010 at 01:37:26PM -0300, Cesar Strauss wrote:
>>
>>> Dear MinGW community,
>>>
>>> I am pleased to announce the MinGW.org release of GCC 4.5.0.
>>>
> *snip*
>> It is probably in your best interest to warn users either in
>> General Notes or Known Issues that exceptions in C++ do not work
>> in multithreaded programs, or, has this been resolved?
>>
>
> Everything works fine in my multithreaded exceptions testcase (as long
> as, per the notes, -Wl,--enable-auto-import is used, but that's not
> related).

Does this mean that we do not need any SJLJ version anymore? And as a
result for example TDM might change the default binaries to DW2 while
maybe keeping the SJLJ version with a suffix (i.e. g++-SJLJ.exe)? I
have seen this confuses people who want to link against a library
build with a different unwinding.

Thanks for the new release, BTW


>
> -John E.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

On 4/19/2010 2:18 PM, Ehsan Azarnasab wrote:
> On Mon, Apr 19, 2010 at 12:45 PM, John E. / TDM<tdragon@...>  wrote:
>    
>> Everything works fine in my multithreaded exceptions testcase (as long
>> as, per the notes, -Wl,--enable-auto-import is used, but that's not
>> related).
>>      
> Does this mean that we do not need any SJLJ version anymore? And as a
> result for example TDM might change the default binaries to DW2 while
> maybe keeping the SJLJ version with a suffix (i.e. g++-SJLJ.exe)? I
> have seen this confuses people who want to link against a library
> build with a different unwinding.
>    

The question of DWARF-2 versus SJLJ unwinding has little to do with 
multithreading, and additionally TDM-GCC isn't supported by this mailing 
list or by the MinGW project in general, but I'll answer your question 
anyway.

The consensus among those responsible for the official MinGW GCC 
releases? No, SJLJ isn't needed anymore. That's why every official 
release since 4.4.0, including this one, has been DWARF-2 unwinding only.

My opinion? Well, there is still code out there that relies on unwinding 
through frames in system DLLs, and that still breaks with DWARF-2. So in 
TDM-GCC I elect to stick with SJLJ unwinding as a reasonable default. 
Since you bring it up, however, I may add some additional language on 
the TDM-GCC site that explains why mixing object code from different GCC 
releases using different unwind mechanisms breaks exceptions.

-John E.

On 4/19/2010 10:37 AM, Cesar Strauss wrote:
> Dear MinGW community,
>
> I am pleased to announce the MinGW.org release of GCC 4.5.0.
>    

...and here's your first bug report! I've submitted PR # 2989578 
(<http://sourceforge.net/tracker/?func=detail&aid=2989578&group_id=2435&atid=102435>), 
in summation of which I'll merely state that libstdc++ fstreams can't 
seek past 2Gb. I also attached the patch I use for it in TDM-GCC to the PR.

Cheers,
John E.

Hi all,

In message "[Mingw-users] MinGW GCC 4.5.0 released",
Cesar Strauss wrote...
 >* When linking C++ modules with shared libstdc++ (the default), the
 >   linker may warn about activating auto-import. The workaround is to
 >   add one of the following flags:
 >   a) -Wl,--enable-runtime-pseudo-reloc-v2
 >      The warning is still printed, but is now harmless.
 >   b) -Wl,--enable-auto-import
 >      Actually does what the warning suggests.
 >   c) -static-libstdc++
 >      Avoids creating the issue in the first place.
 >   d) none of the above.
 >      You may get a 0xc0000005 error at runtime.

What about old -Wl,--enable-runtime-pseudo-reloc ??

b)?

I experienced more frequent ICE with precompiled header enabled than 4.4.0 but I suspect 
it is a con in gcc 4.5.0 itself.

I am going to check if COMDAT for language-defined typeinfo is working well with dynamic 
libstdc++, which is critical for OpenOffice.org build.

Best Regrads,

----
 Takashi Ono(HK Freak)
 mailto:t_ono@...
 http://www.hkfreak.net
 http://hkfreak.cocolog-nifty.com/blog/

First, thanks for the new release. I look forward to using it!

On 4/19/2010 12:37 PM, Cesar Strauss wrote:
> * The path "\mingw\include" on the current drive is always searched for
>    header files, regardless of where the compiler is installed. So, if
>    you want to keep multiple installations separated, better not to use
>    "\mingw" on any drive.

I think this should be considered a bug -- if
   %TMPDIR%/some-random-dir-Hwj201/include/
were always searched, that'd be an oddity, but not of too much concern.
However, \mingw\include is the default installation location for our
installer(s).

So...if I have a "default" installation, and an "alternate" one -- which
I do -- then this just broke my "alternate" installation.

--
Chuck

Charles Wilson wrote:
> First, thanks for the new release. I look forward to using it!
> 
> On 4/19/2010 12:37 PM, Cesar Strauss wrote:
>> * The path "\mingw\include" on the current drive is always searched for
>>    header files, regardless of where the compiler is installed. So, if
>>    you want to keep multiple installations separated, better not to use
>>    "\mingw" on any drive.
> 
> I think this should be considered a bug -- if
>    %TMPDIR%/some-random-dir-Hwj201/include/
> were always searched, that'd be an oddity, but not of too much concern.
> However, \mingw\include is the default installation location for our
> installer(s).
> 
> So...if I have a "default" installation, and an "alternate" one -- which
> I do -- then this just broke my "alternate" installation.

I agree it is a bug. I'll see what I can do.

The issue is not new, however. Try installing any old version, like 
3.4.5, in an alternate path and type:

echo '#include <stdio.h>' | gcc -E -o /dev/null - -v

... and you will see /mingw/include in the search path.

I just thought it was worth mentioning it as a "known isssue".

Cesar

Takashi Ono wrote:
> 
> What about old -Wl,--enable-runtime-pseudo-reloc ??
> 

By itself, it can't cope with some kinds of relocations.
For example:

$ cat app.cpp

class foo
{
   public:
     virtual void bar();
};

void foo::bar()
{
}

int main()
{
   foo f;
   f.bar();
}

$ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc
Info: resolving vtable for __cxxabiv1::__class_type_info by linking to 
__imp___ZTVN10__cxxabiv117__class_type_infoE (auto-import)
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: 
warning: auto-importing has been activated without --enable-auto-import 
specified on the command line.
This should work unless it involves constant data structures referencing 
symbols from auto-imported DLLs.

$ ./app.exe
(Message box with error 0xc0000005 appears)

The following all work:
$ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2
$ g++ -o app.exe app.cpp -Wl,--enable-auto-import
$ g++ -o app.exe app.cpp -static-libstdc++

Regards,
Cesar

On 4/19/2010 9:27 PM, Cesar Strauss wrote:
> The issue is not new, however. Try installing any old version, like 
> 3.4.5, in an alternate path and type:
> 
> echo '#include <stdio.h>' | gcc -E -o /dev/null - -v
> 
> ... and you will see /mingw/include in the search path.

Huh.  I thought that previous versions did not exhibit this behavior; I
guess it's a good thing I don't use my "alternate" installation very
often -- in fact, I usually SWAP the two mingw directories physically...

So, it's a bug -- but not a regression.  That certainly makes it less of
a pressing issue.  Thanks for the clarification.

--
Chuck

----- Original Message ----- 
From: "Charles Wilson" <
> On 4/19/2010 9:27 PM, Cesar Strauss wrote:
>> The issue is not new, however. Try installing any old version, like
>> 3.4.5, in an alternate path and type:
>>
>> echo '#include <stdio.h>' | gcc -E -o /dev/null - -v
>>
>> ... and you will see /mingw/include in the search path.
>
 Yes, but it should be the very  last in the search path and would normally 
be overridden by something like:

#include <...> search starts here:
 c:\path-to-alt-mingw\bin\../lib/gcc/mingw32/4.5.0-dw2/../../../../include

that is, the relative-to-bin prefix.

/mingw/bin is equivalent to /usr/include, as it says in gcc's mingw32.h

/* Override the standard choice of /usr/include as the default prefix
   to try when searching for header files.  */
#undef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR "/mingw/include"

Danny

Cesar Strauss wrote:

> $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc

> The following all work:
> $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2

So why do we have two versions?  One that works and one that doesn't 
work?  Should the original version just go away and become an alias to -v2?

-- 
Earnie
-- http://www.for-my-kids.com

Earnie wrote:
> Cesar Strauss wrote:
> 
>> $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc
> 
>> The following all work:
>> $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2
> 
> So why do we have two versions?  One that works and one that doesn't 
> work?  Should the original version just go away and become an alias to -v2?
> 

Indeed. In binutils CVS, the v2 version is already on by default. So, in 
the future, it will be safe to ignore the auto-import warning (and I am 
working on a patch to silence it altogether).

Regards,
Cesar

Hi Cesar,

I understand that old --enable-runtime-pseudo-reloc is buggy and will cause problem.

I would like to confirm one thing.

You wrote --enable-auto-import and -static-libstdc++ also work. With -static-libstdc++ 
the shared version of libstdc++ will never be used and the story is completely 
different.

However, in case the binary is linkable by --enable-auto-import without unresolved 
reference, no gimmick of runtime-pseudo-reloc is neeeded, I think. Your example means 
--enable-runtime-pseudo-reloc will do some harm even in some case runtime-pseudo-reloc 
is actually not needed? 

In message "Re: [Mingw-users] MinGW GCC 4.5.0 released",
Cesar Strauss wrote...
 >Takashi Ono wrote:
 >> 
 >> What about old -Wl,--enable-runtime-pseudo-reloc ??
 >> 
 >
 >By itself, it can't cope with some kinds of relocations.
 >For example:
 >
 >$ cat app.cpp
 >
 >class foo
 >{
 >   public:
 >     virtual void bar();
 >};
 >
 >void foo::bar()
 >{
 >}
 >
 >int main()
 >{
 >   foo f;
 >   f.bar();
 >}
 >
 >$ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc
 >Info: resolving vtable for __cxxabiv1::__class_type_info by linking to 
 >__imp___ZTVN10__cxxabiv117__class_type_infoE (auto-import)
 >c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: 
 >warning: auto-importing has been activated without --enable-auto-import 
 >specified on the command line.
 >This should work unless it involves constant data structures referencing 
 >symbols from auto-imported DLLs.
 >
 >$ ./app.exe
 >(Message box with error 0xc0000005 appears)
 >
 >The following all work:
 >$ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2
 >$ g++ -o app.exe app.cpp -Wl,--enable-auto-import
 >$ g++ -o app.exe app.cpp -static-libstdc++
 >
 >Regards,
 >Cesar
 >
 >
 >------------------------------------------------------------------------------
 >Download Intel® Parallel Studio Eval
 >Try the new software tools for yourself. Speed compiling, find bugs
 >proactively, and fine-tune applications for parallel performance.
 >See why Intel Parallel Studio got high marks during beta.
 >http://p.sf.net/sfu/intel-sw-dev
 >_______________________________________________
 >MinGW-users mailing list
 >MinGW-users@...
 >
 >This list observes the Etiquette found at 
 >http://www.mingw.org/Mailing_Lists.
 >We ask that you be polite and do the same.  Disregard for the list etiquette may 
cause your account to be moderated.
 >
 >_______________________________________________
 >You may change your MinGW Account Options or unsubscribe at:
 >https://lists.sourceforge.net/lists/listinfo/mingw-users

----
 Takashi Ono(HK Freak)
 mailto:t_ono@...
 http://www.hkfreak.net
 http://hkfreak.cocolog-nifty.com/blog/

Takashi Ono wrote:

> However, in case the binary is linkable by --enable-auto-import without unresolved 
> reference, no gimmick of runtime-pseudo-reloc is neeeded, I think. Your example means 
> --enable-runtime-pseudo-reloc will do some harm even in some case runtime-pseudo-reloc 
> is actually not needed? 

No, sorry to have given this impression. In fact, 
--enable-runtime-pseudo-reloc is currently added by default. So, when 
you specify only -Wl,--enable-auto-import, you are actually using both 
(-Wl,--enable-auto-import,--enable-runtime-pseudo-reloc).

Without runtime-pseudo-reloc, --enable-auto-import would not even work:

$ g++ -o app.exe app.cpp \
-Wl,--enable-auto-import,--disable-runtime-pseudo-reloc

app.cpp:(.rdata$_ZTI3foo[typeinfo for foo]+0x0): variable 'vtable for 
__cxxabiv1::__class_type_info' can't be auto-imported. Please read the 
documentation for ld's --enable-auto-import for details.
collect2: ld returned 1 exit status

As I understand it, an effect of using --enable-auto-import is to move 
constant data from read-only sections in the file to writable sections, 
so runtime-pseudo-reloc can do its job of relocating without throwing an 
access violation (0xc0000005).

One thing runtime-pseudo-reloc-v2 seems to do is to briefly make these 
sections writable in memory at run-time, so --enable-auto-import is no 
longer needed with it.

Regards,
Cesar

Hi Cesar,

In message "Re: [Mingw-users] MinGW GCC 4.5.0 released",
Cesar Strauss wrote...

 >As I understand it, an effect of using --enable-auto-import is to move 
 >constant data from read-only sections in the file to writable sections, 
 >so runtime-pseudo-reloc can do its job of relocating without throwing an 
 >access violation (0xc0000005).

I have clearly understood.

 >One thing runtime-pseudo-reloc-v2 seems to do is to briefly make these 
 >sections writable in memory at run-time, so --enable-auto-import is no 
 >longer needed with it.

Will runtime-pseudo-reloc-v2 do this even when pseudo relocation is not needed?
Or we still have to enable auto-importing if pseudo relocation is not involved?

Best Regards,

----
 Takashi Ono(HK Freak)
 mailto:t_ono@...
 http://www.hkfreak.net
 http://hkfreak.cocolog-nifty.com/blog/