nicolas.delmas | 23 Jul 13:44 2014
Picon

MinGW GCC - v3.4.4

Dear Sir or Madam,

 

My company develops a SSIL4 train application software according to the standard EN50128 v2011.

We use the following compiler:

-          Name : MinGW GCC

-          Version : 3.4.4

-          Language : C

-          OS : Windows

 

As part of this project, I am in charge of tools qualification and I need some more information.

 

Could you send me the known problems list of the previously described compiler please ?

 

 

Yours sincerely,

 

Nicolas DELMAS

 

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe
Jan Bilek | 21 Jul 19:53 2014
Picon

Where to get libgcc_s_sjlj-1.dll for relevant Mingw 4.8.4 build?

Hi,

I'm trying to build a libuv dependant application with the latest Mingw 4.8.4 and resulting binary is asking for libgcc_s_sjlj-1.dll.

  • I can't use -static (or -static-libgcc) when building due to a number of other dynamically linked libraries which are then being forced to be linked statically
  • I can see libgcc_s_sjlj-1.dll being lodged in 4.7.0's lib folder, but this is not present in 4.8.4
  • Using libgcc_s_sjlj-1.dll from Mingw 4.7.0 results in missing entry point for __gxx_personality_sj0 issue
  • Tried building Migw as described in README.gcc-4.8.1-4-mingw32, but no libgcc_s_sjlj-1.dll appeared

I would really appreciate any clues on where to look next.

Thank you,
Jan
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe
Vincent Belaïche | 21 Jul 17:47 2014
Picon

latexmk under MSYS

Hello,

I have been using latexmk perl script under MSYS with the msys perl
5.8.8 (BTW thank for providing this more recent perl!).

latexmk does not work properly MSYS because it uses the USER
environement variable. It needs it because at some point of time it uses
the ps command to find running processes, and it uses it this way:

ps -f -u $USER

This is for some special use case where you need to detect some viewer
pid. When latexmk detects that the OS is MSWindow or Cygwin, this use ps
is sort of disabled.

My question is the following:

Can there be any handling of the MSYS case so that ps command can be
used for that latexmk purpose ?

I would say that:

1) The objective of MSYS as far as I understand is only to be able to
   use autotools under MSW, not to be some alternative *nixy-like MSW
   shell, so this kind of interactive use of latexmk might be out of
   scope of MSYS

2) I think that

     ps -f -u "$USERNAME"

   does the job... but that maybe not sufficient.

3) And then the next question is how to detect that we are in the MSYS
   case and that we can do this, in the cygwin case this viewer pid
   detection function is disabled with the following perl code of
   latexmk:

-----------------------------------------------------------------------
    # When the OS is detected as cygwin, there are two possibilities:
    #    a.  Latexmk was run from an NT prompt, but cygwin is in the
    #        path. Then the cygwin ps command will not see commands
    #        started from latexmk.  So we cannot use it.
    #    b.  Latexmk was started within a cygwin environment.  Then
    #        the ps command works as we need.
    # Only the user, not latemk knows which, so we default to not
    # using the ps command.  The user can override this in a
    # configuration file. 
    $pscmd = 
        'NONE $pscmd variable is not configured to detect running processes';
    $pid_position = -1;     # offset of PID in output of pscmd.  
                            # Negative means I cannot use ps
-----------------------------------------------------------------------

    I think that in the case of MSYS one should check:
    - that $OSTYPE == msys,
    - that perl is a one built for MSYS, and

   that would suffice to discard the case that latexmk is started from
   an NT prompt with NT form of /usr/bin being in the NT path (so with
   ps also in the NT path), because in this case OSTYPE is not supposed
   to be defined. Checking that perl is a one built for MSYS is
   certainly safer, that is why I think that if $OSTYPE == msys but perl
   is not an MSYS perl, latexmk should make some warning.

Comments and feedback are welcome.

   Vincent.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Domonic Tom | 15 Jul 16:49 2014
Picon

Re: Optimize even more (for speed) [-02] - run-time error


<!-- .ExternalClass .ecxhmmessage P { padding:0px; } .ExternalClass body.ecxhmmessage { font-size:12pt; font-family:Calibri; } -->
I'm using MinGW compiler 4.7.1 (Even tried 4.8.1) and am getting a strange error,,, for Release Versions only when  I use the this compiler flag Optimize even more (for speed) [-02].

It's always a fatal error, but only when this option in ticked in my Code::Blocks IDE.  Actually, any Optimization flags [-02], [-01], or [-0], I get this problem.

The error seems to be SIGSEGV, segmentation fault but I the code is definitely correct and runs fine when I don't use this flag.  

Is there a common reason why this is causing a problem?  What would the reason be?

Thanks
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe
David Gressett | 14 Jul 03:07 2014

Building gcc 4.8.3, 4.9.0 for MinGW

I have been working on building  gcc 4.8.3 and 4.9.0. My starting place is the MinGW gcc source
code package for the 4.8.1-4 release: gcc-4.8.1-2-mingw32-src.tar.lzma

I constructed my working source code packages for both of these by downloading the upstream 
gcc 4.8.3 and 4.9.0  source code packages. I made 4.8.3 and 4.9.0 MinGW source packages from
copies of the 4.8.1-4 packages by replacing the original gcc-4.8.1.tar.bz2 with the newer equivalents.

For 4.8.3, I checked all the files that were patched by MinGW patches in the 4.8.1-4 package. They were
unchanged in 4.8.3, so the 4.8.1 patches would easily apply. I did, however, add an additional patch
that fixes the Ada problem that I reported earlier.

FOR 4.9.0, I did no patches; my Ada patch will certainly be needed, as the Ada bug is still present in 
4.9.0, but I do not intend to do any such patches until 4.9.0 is buildable without patches.

I then edited the package.ini file to match the version and patch structure for 4.8.3 and 4.9.0 and
started building.

The results in a nutshell: the 4.8.3 build succeeded, the 4.9.0 build failed.

In more detail:
For 4.8.3:

I scanned through the build log looking for warning diagnostics. I expect that most of these 
could be ignored, but just on general principle, I looked for odd things, and I wanted to
establish a baseline for comparison with the 4.9.0 build.

There are numerous warnings for many different source files.
I only patched one file, so these were probably things that weren't a problem for 4.8.1-4,
and probably still won't be a problem for 4.8.3; there weren't a large number of changes
from 4.8.1 to 4.8.3.

There were a few implicit declaration of function warnings, variable set but not used warnings,
redeclared without dllimport attribute warnings, function declaration isn't a prototype
warnings, and implicit declaration of function warnings.

"ISO C++98 does not support the 'I64' ms_printf length modifier" appeared many times.
" may be used uninitialized in this function" was also frequent.

" left shift count >= width of type" struck me as a bit odd; likewise  "comparison of 
unsigned expression < 0 is always false". These and several others were produced by compilation
of code in a directory named soft-fp. These might be platform-specific corner cases in code 
designed for cross-platform used.

There were a number of warnings from adaint.c, which was  one of the files patched by a 
MinGW local patch.

After the build completed it, I did a "make install" and tested it. I found one glitch very 
quickly. I mostly use Ada for my Windows programming work, and use AdaGIDE as my
development environment. I found that command-line invocations of the Ada tools all
worked perfectly, but AdaGIDE had a problem: it could not tell when a GNATMake build
finished and would wait forever for it to finish. This is not a huge problem in itself, but 
indicates a possible problem in the pipe mechanism that AdaGIDE uses to display the output
of GNATMake, which in turn might be a run-time library problem in the newly-built
GNATMake.  I will have to do more testing on this one.

For 4.9.0: Everything ran smoothly until the build reached the Ada run-time library.
 (Note that this build was made with gcc 4.8.1 before I installed 4.8.3) The offender
was gcc-4.9.0/gcc/ada/adaint.c. Numerous calls to Windows API functions produced
a torrent of warnings; most of these were identical to the ones in the 4.8.3 build which
produced no problems.  A fatal error terminated the build before the compiler reached
the end of adaint.c

After the 4.8.3 install I tried the 4.9.0 build again. It failed at the same place, but with 
better error messages. Here is an example:

"error: cannot convert 'TCHAR* {aka wchar_t*}' to 'LPCSTR {aka const char*}'
 for argument '1' to 'UINT GetDriveTypeA(LPCSTR)"

This looks like a failure of the new mechanism for transparent handling of Unicode
that was introduced in the most recent version of the MinGW w32api. The problem must
be in the 4.9.0 adaint.c, as this worked in 4.8.3, and most of the code is the same.

Just to double-check, I backed up my MinGW directory, and downloaded and unpacked 
the previous w32api and runtime files, overwriting the most recent stuff and built
4.9.0 again. This time, the build zipped right through adaint.c with no problems at all. 
I didn't expect the build to succeed, as there were problably some other things that
I should have installed to be consistent with the older runtime and w32api, and in any
case, the 4.9.0  changes could have brought in any number of problems.
Sure enough, the build died later on after a spectacular shower of warning messages.
Many of these were griping about " unknown conversion type character 'l' in format";
sometimes the offending character was 'r' or 'R'. I'm not going to worry too much
about these at this point, as my focus will be on finding the adaint.c problem with the
latest runtime and win32 api code. It is , however, possible that some of these warnings
come from new demands that  4.9.0 makes on the C runtime library.  I haven't compared
the newer mingwex stuff with the older code, so I don't know if these 'l', 'R', and 'r'
conversion type problems are fixed in the newer code.

My next project for the 4.9.0 build is to shrink adaint.c into something small enough
to use as an investigative test for the win32 API problem.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck&#174;
Code Sight&#153; - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Abalieno | 13 Jul 16:02 2014
Picon

std::stoi broken

It seems std::stoi is still broken, looking up the bug it looks like it 
has been broken for years now.

error: 'stoi' is not a member of 'std'

Can someone point to a fix for the last version of MinGW?

Or should I just give up considering it doesn't look like MinGW is being 
updated anymore?

------------------------------------------------------------------------------
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Jack LaVigne | 11 Jul 03:49 2014
Picon
Picon

Problem building libf2c with mingw-get-setup.exe

In 2011 on a windows 7 system I downloaded
mingw-get-inst-20110316.exe and was able to build libf2c after
make a few changes to makefile.u.

#    Original                  Edit
--   --------                  ----
1    CC = cc                   CC = gcc
2    SHELL = /bin/sh           # SHELL = /bin/sh
3    CFLAGS = -O               CFLAGS = -DMSDOS -O
4    ./a.out >arith.h          /d/libf2c/a.exe >arith.h
5    rm -f a.out arithchk.o    rm -f a.exe arithchk.o

Now in 2014 on a new computer (same windows 7 I think) I was
unable to download mingw-get-inst-20110316.exe and ended up using
mingw-get-setup.exe.

I asked for the same components as in 2011:

      mingw-developer-toolkig
      mingw32-base
      mingw32-gcc-fortran
      mingw32-gcc-g++
      msys-base

I was able to compile some simple test c programs succesfully.

However I have a problem building libf2c.

I made the same changes to the libf2c makefile.u as in 2011 but
now I get an error message.

uninit.c: In function 'ieee0':
uninit.c:161:21: error: '_EM_DENORMAL' undeclared (first use in this
function)
 #define EM_DENORMAL _EM_DENORMAL
                     ^
uninit.c:172:13: note: in expansion of macro 'EM_DENORMAL'
  _control87(EM_DENORMAL | EM_UNDERFLOW | EM_INEXACT, MCW_EM);
             ^
uninit.c:161:21: note: each undeclared identifier is reported only once for
each function it appears in
 #define EM_DENORMAL _EM_DENORMAL
                     ^
uninit.c:172:13: note: in expansion of macro 'EM_DENORMAL'
  _control87(EM_DENORMAL | EM_UNDERFLOW | EM_INEXACT, MCW_EM);
             ^
uninit.c:164:22: error: '_EM_UNDERFLOW' undeclared (first use in this
function)
 #define EM_UNDERFLOW _EM_UNDERFLOW
                      ^
uninit.c:172:27: note: in expansion of macro 'EM_UNDERFLOW'
  _control87(EM_DENORMAL | EM_UNDERFLOW | EM_INEXACT, MCW_EM);
                           ^
uninit.c:167:20: error: '_EM_INEXACT' undeclared (first use in this
function)
 #define EM_INEXACT _EM_INEXACT
                    ^
uninit.c:172:42: note: in expansion of macro 'EM_INEXACT'
  _control87(EM_DENORMAL | EM_UNDERFLOW | EM_INEXACT, MCW_EM);
                                          ^
uninit.c:170:16: error: '_MCW_EM' undeclared (first use in this function)
 #define MCW_EM _MCW_EM
                ^
uninit.c:172:54: note: in expansion of macro 'MCW_EM'
  _control87(EM_DENORMAL | EM_UNDERFLOW | EM_INEXACT, MCW_EM);
                                                      ^
make: *** [uninit.o] Error 1

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Chris Angelico | 7 Jul 09:51 2014
Picon

Error: The _WIN32_WINNT value does not match NTDDI_VERSION

Minimal test-case:

#define _WIN32_WINNT 0x0500
#define NTDDI_VERSION 0x05000000
#include <windows.h>

I have a WinXP virtual machine on which I just installed a fresh mingw
and msys (today), in order to try to cross-compile stuff for Windows.
Failing with the subject error, because in sdkddkver.h are the
following lines:

#    if _WIN32_WINNT != OSVER(NTDDI_VERSION)
#      error The _WIN32_WINNT value does not match NTDDI_VERSION
#    endif

According to 'gcc -dM -E' on the above code, OSVER is defined thus:

#define OSVER(ver) ((ver) & OSVERSION_MASK)
#define OSVERSION_MASK 0xFFFF0000

I think possibly the right macro to use here is not OSVER, but WINNTVER:

#define WINNTVER(ver) ((ver) / 0x00010000)

With this change, the test case and the original code appear to
compile successfully. I'm not sure it's right, though; advice?

Chris Angelico

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

sasha | 7 Jul 07:35 2014
Picon

http://vmpsoft.com/

i use VMProtect. But due to the fact that the mingw changes the import 
doesn't work, since the protector cannot read CRC. Something can be done 
to mingw did not change the exe on the runtime ?

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Sourav Mukherjee | 4 Jul 08:11 2014
Picon

unable to allocate heap while building clang with mingw, msys on windows 7

I'm trying to build clang as instructed over here
http://pete.akeo.ie/2011/10/building-and-running-clang-static.html I
'm getting a heap allocation error while running the configure command
script shown below.
When I'm doing :-

sh --verbose configure --disable-docs --enable-optimized
--enable-targets=x86,x86_64 --prefix=/mingw

I get this error:-
C:\MinGW\msys\1.0\bin\sh.exe: * 1. unable to allocate heap 0x10060000,
heap_ch unk_size 268435456, pid 7788, Win32 error 0 0 [main] sh 5548
sync_with_child: child 7788(0x2D8) died before initializa tion with
status code 0x1 555 [main] sh 5548 sync_with_child: * child state
waiting for longjmp ../llvm/configure: fork: Resource temporarily
unavailable

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Manuel De Matos | 4 Jul 16:28 2014

RE : Re: missing symbol __ms_vsnprintf when linking with cross-compiled library


Ok,
Tanks for the clarification,  Il didn't think that they are 2 differents projets. 
I'll make my toolchains consistent, this will solve my problem

Regards,
Manuel

Envoyé depuis un mobile Samsung


-------- Message d'origine --------
De : Eli Zaretskii <at> gnu.org>
Date :04/07/2014 15:45 (GMT+01:00)
À : Manuel de Matos <at> apissys.com>
Cc : mingw-users <at> lists.sourceforge.net
Objet : Re: [Mingw-users] missing symbol __ms_vsnprintf when linking with cross-compiled library

> From: "Manuel de Matos" <mdematos <at> apissys.com>
> Date: Fri, 4 Jul 2014 14:47:52 +0200
>
> You are right about the 64/32 bit version mismatch.

No, it's not the 32/64 bit mismatch.  It's a mismatch between 2 subtly
incompatible MinGW development environments: one produced and
supported by mingw.org (which this list is about), the other MinGW64,
a different project.  (The "64" part is not really about 64 bits, it's
just a different name.)

> I could check the MinGW version on my windows install :
> _mingw.h:#define __MINGW32_VERSION           3.20
> w32api.h:#define __W32API_VERSION 3.17
>
> for the Linux install I found these values:
> _mingw_mac.h:#define __MINGW32_MAJOR_VERSION 3
> _mingw_mac.h:#define __MINGW32_MINOR_VERSION 11
>
> _mingw_mac.h:#define __MINGW64_VERSION_MAJOR 3
> _mingw_mac.h:#define __MINGW64_VERSION_MINOR 1
>
> w32api.h:#define __W32API_VERSION 3.14

These are telltale signs of the problem I guessed: mingw.org does not
have the _mingw_mac.h header.

> BTW, I have ask a colleague  perform the link with his Linux mingw64
> toolchain (4.6.xx, MINGW64 version 2.0, MMINGW32 version 3.11, W32API 3.14),
> he had the same unresolved symbol.

I think he uses an incompatible runtime.

> My question is : is it possible to ensure that my cross-compiled library
> will be generates on one side and  linkable on the other side with quite
> recent MinGW toolchain independently of its flavor 32/ 64bit.

It's not the bit-flavor issue.  You do need to ensure you use the same
headers and libraries on both sides of the cross.

> Indeed, this library is aimed to be distributed to clients who have
> different version of MinGW.
> Or, should I embed my own __ms_vsnprintf when I cross-compile on Linux to
> ensure this portability?

I don't think this will solve the problem, since that symbol should
jump to the MS-provided vsnprintf in MSVCRT.DLL, the C runtime DLL on
Windows.

Perhaps just avoid calling vsnprintf altogether.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
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
Also: mailto:mingw-users-request@...?subject=unsubscribe

Gmane