New mingwrt

[Chris Sutcliffe-2]

I'm almost ready to release a new mingwrt to address the issues with GCC 4.4.0.

Keith, one of the changes I would like to commit is the one you
supplied a patch for:

https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2009559&group_id=2435

I have verified that it works correctly for Cygwin.  Would you like me
to commit it, or would you prefer to?

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Monday 27 July 2009 18:16:33 Chris Sutcliffe wrote:

> I'm almost ready to release a new mingwrt to address the issues
> with GCC 4.4.0.
>
> Keith, one of the changes I would like to commit is the one you
> supplied a patch for:
>
> https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2009559&group_id=2435
>
> I have verified that it works correctly for Cygwin.  Would you
> like me to commit it, or would you prefer to?

I've done it, Chris.

I noticed you made some changes to mingwex/stdio/pformat.c, to avoid
some warnings with gcc-4.4.  I was curious, so I had a look:

@@ -734,7 +734,8 @@
    * his `__gdtoa()' function in a manner to provide extended precision
    * replacements for `ecvt()' and `fcvt()'.
    */
-  unsigned int k, e = 0; char *ep;
+  int k;
+  unsigned int e = 0; char *ep;
   static FPI fpi = { 64, 1-16383-64+1, 32766-16383-64+1, FPI_Round_near, 0 };
 
   /* Classify the argument into an appropriate `__gdtoa()' category...

Okay.  Did the __gdtoa() prototype change, with the last round of
updates, or did I just have a signed/unsigned mismatch first time
around?

@@ -1816,7 +1817,7 @@
       /* Save the current format scan position, so that we can backtrack
        * in the event of encountering an invalid format specification...
        */
-      char *backtrack = fmt;
+      const char *backtrack = fmt;
 
       /* Restart capture for dynamic field width and precision specs...
        */

Okay; const makes sense here.

@@ -1882,7 +1883,8 @@
        * `wchar_t' data, (which is promoted to an `int' argument)...
        */
       argval.__pformat_ullong_t = (wchar_t)(va_arg( argv, int ));
-      __pformat_wputchars( (wchar_t *)(&argval), 1, &stream );
+        void *tmp = &argval;
+      __pformat_wputchars( (wchar_t *)tmp, 1, &stream );
     }
 
     else

This one just looks plain wrong!  I'm guessing that the warning was
related to casting from a union with an aggregate size of 64-bits,
(to accommodate the unsigned long long element) to a type with a size
of only 16-bits.  Implicitly casting the address of the union to a
void* may circumvent the warning, but it doesn't seem right that it
should; (we are still passing the address of a 64-bit aggregate to
a function expecting a 16-bit parameter's address).  Surely the more
correct solution would be to pass the address of an element of the
union, which represents an appropriate data type directly.  (Of
course, whichever solution we adopt, the effect is going to be the
same; this is just gcc-4.4 being ultra-pernickity, where we know
that the cast is safe, whichever way we write it).

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

Hey Keith,

>> I have verified that it works correctly for Cygwin.  Would you
>> like me to commit it, or would you prefer to?
>
> I've done it, Chris.

Excellent, thank you!

> I noticed you made some changes to mingwex/stdio/pformat.c, to avoid
> some warnings with gcc-4.4.  I was curious, so I had a look:
>
> @@ -734,7 +734,8 @@
>    * his `__gdtoa()' function in a manner to provide extended precision
>    * replacements for `ecvt()' and `fcvt()'.
>    */
> -  unsigned int k, e = 0; char *ep;
> +  int k;
> +  unsigned int e = 0; char *ep;
>   static FPI fpi = { 64, 1-16383-64+1, 32766-16383-64+1, FPI_Round_near, 0 };
>
>   /* Classify the argument into an appropriate `__gdtoa()' category...
>
> Okay.  Did the __gdtoa() prototype change, with the last round of
> updates, or did I just have a signed/unsigned mismatch first time
> around?

The __gdtoa() prototype may have changed with the massive update to
the math functions.  Either way, as you pointed out, there was signed
/ unsigned mismatch.

> @@ -1882,7 +1883,8 @@
>               * `wchar_t' data, (which is promoted to an `int' argument)...
>               */
>              argval.__pformat_ullong_t = (wchar_t)(va_arg( argv, int ));
> -             __pformat_wputchars( (wchar_t *)(&argval), 1, &stream );
> +        void *tmp = &argval;
> +             __pformat_wputchars( (wchar_t *)tmp, 1, &stream );
>            }
>
>            else
>
> This one just looks plain wrong!  I'm guessing that the warning was
> related to casting from a union with an aggregate size of 64-bits,
> (to accommodate the unsigned long long element) to a type with a size
> of only 16-bits.  Implicitly casting the address of the union to a
> void* may circumvent the warning, but it doesn't seem right that it
> should; (we are still passing the address of a 64-bit aggregate to
> a function expecting a 16-bit parameter's address).  Surely the more
> correct solution would be to pass the address of an element of the
> union, which represents an appropriate data type directly.  (Of
> course, whichever solution we adopt, the effect is going to be the
> same; this is just gcc-4.4 being ultra-pernickity, where we know
> that the cast is safe, whichever way we write it).

Agreed, looking at this in the larger scope of this function, and in
particular the members of the union, this was not the most elegant
appoach to correcting the issue.  I've checked in a different fix to
address the issue by using the exist void * (__pformat_ptr_t) member
of the union and type casting it to wchar_t *.

The net result is the same, I think it's just a more elegant implementation.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Tuesday 28 July 2009 02:32:17 Chris Sutcliffe wrote:
> Agreed, looking at this in the larger scope of this function, and
> in particular the members of the union, this was not the most
> elegant appoach to correcting the issue.  I've checked in a
> different fix to address the issue by using the exist void *
> (__pformat_ptr_t) member of the union and type casting it to
> wchar_t *.
>
> The net result is the same, I think it's just a more elegant
> implementation.

Sorry Chris, but I'm afraid the net result is *not* the same; your
latest patch interprets a wchar_t *value* as if it were a pointer,
which is then passed to the output helper as the *address* of that
value.  This clearly isn't correct.

I can't reproduce any warning with gcc-4.2, even with the original
pformat.c implementation, and I haven't yet had time to build a
cross mingw32-gcc-4.4.  Does the attached alternative avoid the
warning for your build case?

--

Regards,
Keith.

? autom4te.cache
? build
? patches
? xx
? mingwex/math/asinh_generic.c
? mingwex/math/fastmath.h.in
Index: mingwex/stdio/pformat.c
===================================================================
RCS file: /cvs/src/src/winsup/mingw/mingwex/stdio/pformat.c,v
retrieving revision 1.6
diff -u -r1.6 pformat.c
--- mingwex/stdio/pformat.c 28 Jul 2009 01:28:22 -0000 1.6
+++ mingwex/stdio/pformat.c 28 Jul 2009 19:17:39 -0000
@@ -734,8 +734,7 @@
    * his `__gdtoa()' function in a manner to provide extended precision
    * replacements for `ecvt()' and `fcvt()'.
    */
-  int k;
-  unsigned int e = 0; char *ep;
+  int k; unsigned int e = 0; char *ep;
   static FPI fpi = { 64, 1-16383-64+1, 32766-16383-64+1, FPI_Round_near, 0 };
 
   /* Classify the argument into an appropriate `__gdtoa()' category...
@@ -1882,8 +1881,8 @@
       /* considering any `long' type modifier as a reference to
        * `wchar_t' data, (which is promoted to an `int' argument)...
        */
-      argval.__pformat_ullong_t = (wchar_t)(va_arg( argv, int ));
-      __pformat_wputchars( (wchar_t *)argval.__pformat_ptr_t, 1, &stream );
+      wchar_t argval = (wchar_t)(va_arg( argv, int ));
+      __pformat_wputchars( &argval, 1, &stream );
     }
 
     else

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

> Sorry Chris, but I'm afraid the net result is *not* the same; your
> latest patch interprets a wchar_t *value* as if it were a pointer,
> which is then passed to the output helper as the *address* of that
> value.  This clearly isn't correct.

D'oh, yep, dunno what I was thinking...  No more late night patching for me.

> I can't reproduce any warning with gcc-4.2, even with the original
> pformat.c implementation, and I haven't yet had time to build a
> cross mingw32-gcc-4.4.  Does the attached alternative avoid the
> warning for your build case?

Your patch worked like a charm.  I can honestly say it never occurred
to me to recast argval when setting it in the first place, in fact I
didn't know that it was valid to do so, so I've learned something new.

Thank you for the patch, would you like to commit it, or would you prefer I do?

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Tuesday 28 July 2009 23:50:32 Chris Sutcliffe wrote:
> Your patch worked like a charm.  I can honestly say it never
> occurred to me to recast argval when setting it in the first
> place, in fact I didn't know that it was valid to do so, so I've
> learned something new.

It doesn't recast it, as such; it creates a completely distint entity
which just happens to have the same name, but is visible only within
the inner scope.  (It also hides the more widely scoped entity, in
the inner scope, but we don't need it there).  On leaving the inner
scope, that redefined replacement entity is destroyed, and the
original becomes visible again, (and it remains unchanged).

> Thank you for the patch, would you like to commit it, or would you
> prefer I do?

Tis done.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

>> Your patch worked like a charm.  I can honestly say it never
>> occurred to me to recast argval when setting it in the first
>> place, in fact I didn't know that it was valid to do so, so I've
>> learned something new.
>
> It doesn't recast it, as such; it creates a completely distint entity
> which just happens to have the same name, but is visible only within
> the inner scope.  (It also hides the more widely scoped entity, in
> the inner scope, but we don't need it there).  On leaving the inner
> scope, that redefined replacement entity is destroyed, and the
> original becomes visible again, (and it remains unchanged).

Cool, thank you for the detailed explanation.

>> Thank you for the patch, would you like to commit it, or would you
>> prefer I do?
>
> Tis done.

Excellent, I'll roll a new release tonight and upload it.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Wednesday 29 July 2009 13:43:02 Chris Sutcliffe wrote:
> Cool, thank you for the detailed explanation.

You're welcome.

> >> Thank you for the patch, would you like to commit it, or would
> >> you prefer I do?
> >
> > Tis done.

Arrrgh!  I missed out an asterisk, (as bullet mark), from my
ChangeLog entry; if you see this in time, perhaps you would be so
kind as to insert it...

> Excellent, I'll roll a new release tonight and upload it.

...when you add the record for this.  Thanks.

--

Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

> Arrrgh!  I missed out an asterisk, (as bullet mark), from my
> ChangeLog entry; if you see this in time, perhaps you would be so
> kind as to insert it...
>
>> Excellent, I'll roll a new release tonight and upload it.
>
> ...when you add the record for this.  Thanks.

I've added the missing asterisic and have rolled the new tarballs, but
it occurred to me that mingw10.dll is missing in the -dev package.  I
added to the 3.15.2 release after releasing it to accomodate the
installer.  My question is, given the effort Keith and Chuck put in to
the naming scheme, and given how gcc-4.4 is packaged, should I add
mingw10.dll to the -dev package again, or simply leave it in the -dll
package?

Additionally, are we still updating mingw.ini for the installer?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Thursday 30 July 2009 03:09:22 Chris Sutcliffe wrote:
> I've added the missing asterisic...

Thanks, Chris.  I didn't mean you to make any special effort to add
it; when next you had anything more concrete to add would have been
sufficient, but no matter...

> I added to the 3.15.2 release after releasing it to accomodate the
> installer.  My question is, given the effort Keith and Chuck put
> in to the naming scheme, and given how gcc-4.4 is packaged, should
> I add mingw10.dll to the -dev package again, or simply leave it in
> the -dll package?

It should be in the -dll package only, and the installer should be
updated to accommodate that; (I suppose simply adding it to the file
manifest in mingw.ini would be too much wishful thinking).

> Additionally, are we still updating mingw.ini for the installer?

For the time being, yes please.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

>> I added to the 3.15.2 release after releasing it to accomodate the
>> installer.  My question is, given the effort Keith and Chuck put
>> in to the naming scheme, and given how gcc-4.4 is packaged, should
>> I add mingw10.dll to the -dev package again, or simply leave it in
>> the -dll package?
>
> It should be in the -dll package only, and the installer should be
> updated to accommodate that; (I suppose simply adding it to the file
> manifest in mingw.ini would be too much wishful thinking).

Unfortunately, as I recall when we investigated this for 3.15.2, the
installer expects only one entry for runtime, which is why I ended up
adding the dll to the -dev package.

>> Additionally, are we still updating mingw.ini for the installer?
>
> For the time being, yes please.

This being the case, should I add the dll to the -dev package again?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Thursday 30 July 2009 19:42:34 Chris Sutcliffe wrote:
> > It should be in the -dll package only, and the installer should
> > be updated to accommodate that; (I suppose simply adding it to
> > the file manifest in mingw.ini would be too much wishful
> > thinking).
>
> Unfortunately, as I recall when we investigated this for 3.15.2,
> the installer expects only one entry for runtime, which is why I
> ended up adding the dll to the -dev package.

Indeed.  The installer seems to declare a few very specific single
valued variables, then just read their values from mingw.ini; IMO,
this is a very poor design restriction, which will definitely not be
reproduced in mingw-get.

> >> Additionally, are we still updating mingw.ini for the
> >> installer?
> >
> > For the time being, yes please.
>
> This being the case, should I add the dll to the -dev package
> again?

No, we should fix the installer, at least to the extent that it adds
say a runtimeDLL variable[*], to which you can assign the tarball.

[*] Okay, I'm saying this as if it should be trivial.  I'm no expert
on NSIS, but it looks like it shouldn't be too difficult; the attached
patch seems to do the trick, but perhaps someone more experienced with
NSIS than I am could review it, before I commit it?

--

Regards,
Keith.

2009.07.31  Keith Marshall  <keithmarshall@...>

        * mingw.nsi (PRODUCT_VERSION): Increment to 5.1.5.
        (runtimeDLL): New variable; declare it; assign to...
        (SecRuntimeDLL): ...this new section; process it.
        (INIfiles): Update all references; make them match...
        (inifiles): ...this actual directory name.

        * MinGW_LICENSE.rtf: Update for new PRODUCT_VERSION.

        * mingw.ini (Filename): Update to match PRODUCT_VERSION.
        (runtimeDLL): Assign it.

Index: MinGW_LICENSE.rtf
===================================================================
RCS file: /cvsroot/mingw/MinGW/Attic/MinGW_LICENSE.rtf,v
retrieving revision 1.7
diff -u -r1.7 MinGW_LICENSE.rtf
--- MinGW_LICENSE.rtf 13 May 2008 00:32:56 -0000 1.7
+++ MinGW_LICENSE.rtf 31 Jul 2009 18:47:42 -0000
@@ -1,7 +1,7 @@
 {\rtf1\ansi\ansicpg1252\deff0\deflang1033\deflangfe1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 Arial;}{\f1\froman\fprq2\fcharset0 Times New Roman;}{\f2\fscript\fprq2\fcharset0 Comic Sans MS;}}
 {\colortbl ;\red0\green0\blue255;}
 \viewkind4\uc1\pard\nowidctlpar\qc\b\f0\fs28 Minimal GNU for Windows\par
-\i\fs24 Version 5.1.4\par
+\i\fs24 Version 5.1.5\par
 \cf1\ul\i0\f1\fs20 http://www.mingw.org/\cf0\ulnone\i\f0\fs24\par
 \pard\nowidctlpar\b0\i0\f1\fs20\par
 \pard\nowidctlpar\qc\f0\fs24 License, Use and Redistribution\par
@@ -17,4 +17,4 @@
 Earnie.\par
 Earnie@...\par
 }
-
+
Index: mingw.nsi
===================================================================
RCS file: /cvsroot/mingw/MinGW/Attic/mingw.nsi,v
retrieving revision 1.9
diff -u -r1.9 mingw.nsi
--- mingw.nsi 13 May 2008 00:32:56 -0000 1.9
+++ mingw.nsi 31 Jul 2009 18:47:42 -0000
@@ -6,7 +6,7 @@
 
 ; HM NIS Edit Wizard helper defines
 !define PRODUCT_NAME "MinGW"
-!define PRODUCT_VERSION "5.1.4"
+!define PRODUCT_VERSION "5.1.5"
 !define PRODUCT_PUBLISHER "MinGW"
 !define PRODUCT_WEB_SITE "http://www.mingw.org"
 !define PRODUCT_UNINST_KEY "Software\Microsoft\Windows\CurrentVersion\Uninstall\${PRODUCT_NAME}"
@@ -110,6 +110,7 @@
 var Package
 
 var runtime
+var runtimeDLL
 var W32API
 var binutils
 var Core
@@ -128,6 +129,9 @@
   Section runtime SecRuntime
     SectionIn 1 2 3
   SectionEnd
+  Section runtime SecRuntimeDLL
+    SectionIn 1 2 3
+  SectionEnd
   Section w32api SecW32API
     SectionIn 1 2
   SectionEnd
@@ -168,6 +172,10 @@
   push $runtime
   Call DownloadIfNeeded
 
+  push ${SecRuntimeDLL}
+  push $runtimeDLL
+  Call DownloadIfNeeded
+
   push ${SecW32API}
   push $W32API
   Call DownloadIfNeeded
@@ -209,7 +217,7 @@
   IntCmp $Updating 1 skipwrite +1
   
   CreateDirectory $INSTDIR
-  File /oname=$INSTDIR\installed.ini INIfiles\installed.ini
+  File /oname=$INSTDIR\installed.ini inifiles\installed.ini
 
   WriteINIStr $INSTDIR\installed.ini "settings"  "installtype" $Package
 
@@ -219,6 +227,11 @@
   push "runtime"
   Call ExtractTarball
 
+  push ${SecRuntimeDLL}
+  push $runtimeDLL
+  push "runtimeDLL"
+  Call ExtractTarball
+
   push ${SecW32API}
   push $W32API
   push "w32api"
@@ -358,7 +371,7 @@
 
 extractINI:
   ; extract built in ini file
-  File /oname=$EXEDIR\mingw.ini INIfiles\mingw.ini
+  File /oname=$EXEDIR\mingw.ini inifiles\mingw.ini
   ReadINIStr $R1 "$EXEDIR\mingw.ini" "mingw" "Build"
 
 downloadINI:
@@ -418,6 +431,7 @@
 
 first_install:
   SectionSetText ${SecRuntime} ""
+  SectionSetText ${SecRuntimeDLL} ""
   SectionSetText ${SecW32API} ""
   SectionSetText ${SecBinutils} ""
   SectionSetText ${SecCore} ""
@@ -649,6 +663,14 @@
   ${StrTok} $R1 $R0 "|" 1 0
   SectionSetSize ${SecRuntime} $R1
 
+  ReadINIStr $R0 "$EXEDIR\mingw.ini" $Package "runtimeDLL"
+  ${If} $R0 == ""
+    ReadINIStr $R0 "$EXEDIR\mingw.ini" current "runtimeDLL"
+  ${EndIf}
+  ${StrTok} $runtimeDLL $R0 "|" 0 0
+  ${StrTok} $R1 $R0 "|" 1 0
+  SectionSetSize ${SecRuntimeDLL} $R1
+
   ReadINIStr $R0 "$EXEDIR\mingw.ini" $Package "w32api"
   ${If} $R0 == ""
     ReadINIStr $R0 "$EXEDIR\mingw.ini" current "w32api"
@@ -717,6 +739,12 @@
   push ${SecRuntime}
   call CheckVersion
   
+  ReadINIStr $R0 "$INSTDIR\installed.ini" "components" "runtimeDLL"
+  push $R0
+  push $runtimeDLL
+  push ${SecRuntimeDLL}
+  call CheckVersion
+  
   ReadINIStr $R0 "$INSTDIR\installed.ini" "components" "w32api"
   push $R0
   push $W32API
Index: inifiles/mingw.ini
===================================================================
RCS file: /cvsroot/mingw/MinGW/inifiles/Attic/mingw.ini,v
retrieving revision 1.19
diff -u -r1.19 mingw.ini
--- inifiles/mingw.ini 14 May 2008 22:43:23 -0000 1.19
+++ inifiles/mingw.ini 31 Jul 2009 18:47:43 -0000
@@ -1,13 +1,14 @@
 [mingw]
 Build=11
 URL=http://prdownloads.sourceforge.net/mingw
-Filename=MinGW-5.1.4.exe
+Filename=MinGW-5.1.5.exe
 packages=previous|current|candidate
 
 [current]
-runtime=mingw-runtime-3.14.tar.gz|6500
-w32api=w32api-3.11.tar.gz|14500
-binutils=binutils-2.17.50-20060824-1.tar.gz|21940
+runtime=mingwrt-3.15.2-mingw32-dev.tar.gz|7616
+runtimeDLL=mingwrt-3.15.2-mingw32-dll.tar.gz|40
+w32api=w32api-3.13-mingw32-dev.tar.gz|14420
+binutils=binutils-2.19.1-mingw32-bin.tar.gz|21093
 core=gcc-core-3.4.5-20060117-3.tar.gz|7712
 gpp=gcc-g++-3.4.5-20060117-3.tar.gz|15480
 g77=gcc-g77-3.4.5-20060117-3.tar.gz|5272
@@ -17,9 +18,9 @@
 make=mingw32-make-3.81-20080326-2.tar.gz|727
 
 [previous]
-runtime=mingw-runtime-3.13.tar.gz|5420
-w32api=w32api-3.10.tar.gz|14490
-binutils=binutils-2.16.91-20060119-1.tar.gz|15850
+runtime=mingw-runtime-3.14.tar.gz|6500
+w32api=w32api-3.11.tar.gz|14500
+binutils=binutils-2.17.50-20060824-1.tar.gz|21940
 core=gcc-core-3.4.2-20040916-1.tar.gz|8627
 gpp=gcc-g++-3.4.2-20040916-1.tar.gz|16542
 g77=gcc-g77-3.4.2-20040916-1.tar.gz|5158

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

>> This being the case, should I add the dll to the -dev package
>> again?
>
> No, we should fix the installer, at least to the extent that it adds
> say a runtimeDLL variable[*], to which you can assign the tarball.
>
> [*] Okay, I'm saying this as if it should be trivial.  I'm no expert
> on NSIS, but it looks like it shouldn't be too difficult; the attached
> patch seems to do the trick, but perhaps someone more experienced with
> NSIS than I am could review it, before I commit it?

Fair enough, I'm on vacation for the next week, leaving first thing
tomorrow morning.  I'll upload the new mingwrt when I get back.
Hopefully the installer will be updated by the time I return.

Cheers!

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

>> [*] Okay, I'm saying this as if it should be trivial.  I'm no expert
>> on NSIS, but it looks like it shouldn't be too difficult; the attached
>> patch seems to do the trick, but perhaps someone more experienced with
>> NSIS than I am could review it, before I commit it?
>
> Fair enough, I'm on vacation for the next week, leaving first thing
> tomorrow morning.  I'll upload the new mingwrt when I get back.
> Hopefully the installer will be updated by the time I return.

The patch to the installer looks good to me.  I'm also ready to upload
the updated mingwrt.  Should I proceed with the upload and the
announcement?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr