[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mingw-notify
Subject:    MinGW-notify Digest, Vol 54, Issue 4
From:       mingw-notify-request () lists ! sourceforge ! net
Date:       2010-11-20 21:13:08
Message-ID: mailman.61999.1290287588.5007.mingw-notify () lists ! sourceforge ! net
[Download RAW message or body]

Send MinGW-notify mailing list submissions to
	mingw-notify@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
	mingw-notify-request@lists.sourceforge.net

You can reach the person managing the list at
	mingw-notify-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."


This list is used to send updates of submitted patches, bug reports and file \
releases.  You are discouraged from posting to this list.  If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.

Today's Topics:

   1. [ mingw-Patches-3105314 ] mingw crashes with	experimental GCC
      4.6.0 (SF/projects/mingw notification list)
   2. [ mingw-Bugs-3079289 ] Missing m4 macros: AC_SUBST,
      AC_MSG_ERROR, PKG_CHECK_MODULES (SF/projects/mingw notification list)
   3. [ mingw-Patches-3106671 ] trivial header fixups
      (SF/projects/mingw notification list)
   4. [ mingw-Bugs-3107222 ] Missing structs in psapi.h
      (SF/projects/mingw notification list)
   5. [ mingw-Bugs-3109481 ] mingw-get-inst-20101030.exe	fails to
      install Objective-C (SF/projects/mingw notification list)
   6. [ mingw-Patches-3113782 ] Define INT8, UINT8, INT16,	and
      UINT16 (SF/projects/mingw notification list)
   7. [ mingw-Patches-3081421 ] Allow inherited error mode.
      (SF/projects/mingw notification list)


----------------------------------------------------------------------

Message: 1
Date: Mon, 08 Nov 2010 14:56:21 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3105314 ] mingw crashes with
	experimental GCC 4.6.0
To: noreply@sourceforge.net
Message-ID: <E1PFT8v-0006UI-Ps@sfs-web-8.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Patches item #3105314, was opened at 2010-11-08 15:56
Message generated for change (Tracker Item Submitted) made by rodrigo_rc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3105314&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rodrigo (rodrigo_rc)
Assigned to: Nobody/Anonymous (nobody)
Summary: mingw crashes with experimental GCC 4.6.0

Initial Comment:
I've been compiling the MinGW suite from the GCC SVN tree, and it compiles without \
problems, but then the compiled executables crash in the MinGW initialization. I've \
managed to locate the error: it is in the file winsup/mingw/tlssup.c, function \
__dyn_tls_init. The issue here seems to be that the new GCC optimizes away the \
comparison before the first iteration of the loop, so if the list is empty (which is \
in simple test programs), it crashes.

The patch below solves the issue by avoiding the comparison between pointers to \
global variables.

Regards.
Rodrigo

--- tlssup.c.bak	2010-11-08 17:52:14.429153002 +0100
+++ tlssup.c	2010-11-08 17:52:35.921153000 +0100
@@ -94,6 +94,7 @@
 __dyn_tls_init (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
 {
   _PVFV *pfunc;
+  int nfuncs, ifunc;
 
 #ifndef _WIN64
   if (_winmajor < 4)
@@ -130,8 +131,10 @@
       return TRUE;
     }
 
-  for (pfunc = &__xd_a + 1; pfunc != &__xd_z; ++pfunc)
+  nfuncs = &__xd_z - (&__xd_a + 1);
+  for (ifunc = 0; ifunc < nfuncs; ++ifunc)
     {
+      pfunc = (&__xd_a + 1) + ifunc;
       if (*pfunc != NULL)
 	(*pfunc)();
     }

Changelog:

mingw/

2010-11-08  Rodrigo Rivas Costa  <rodrigorivascosta@gmail.com>

	* tlssup.c (__dyn_tls_init): Use an integer variable to iterate between
	__xd_a and __xd_z.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3105314&group_id=2435



------------------------------

Message: 2
Date: Wed, 10 Nov 2010 09:20:04 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3079289 ] Missing m4 macros:
	AC_SUBST,	AC_MSG_ERROR, PKG_CHECK_MODULES
To: noreply@sourceforge.net
Message-ID: <E1PG6qa-0006nD-1P@sec-sog-1.v99.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Bugs item #3079289, was opened at 2010-10-01 09:13
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3079289&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
> Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing m4 macros: AC_SUBST, AC_MSG_ERROR, PKG_CHECK_MODULES

Initial Comment:
When I try to compile gstreamer package gst-template I get the following errors:

/*snip*/

configure.ac:31: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:52: error: possibly undefined macro: AC_SUBST
autoreconf: /usr/bin/autoconf-2.67 failed with exit status: 1
autogen.sh failed

If I add

m4_pattern_allow([^dnl]) 
m4_pattern_allow([^AC_])
m4_pattern_allow([^AS_])
m4_pattern_allow([^m4])

to the beginning of configure.ac I get the following error:

/*snip*/

./configure: line 11204: syntax error near unexpected token `GST,'
./configure: line 11204: `PKG_CHECK_MODULES(GST,'
configure failed

I think these macros are missing from MinGW environment.

----------------------------------------------------------------------

> Comment By: SourceForge Robot (sf-robot)
Date: 2010-11-10 09:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 30 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-10-11 08:44

Message:
Using m4_pattern_allow, as you have, is almost certainly the wrong thing to
do.

The error you report is most often indicative of improper quoting within
configure.ac, particularly when it refers to macros in the AC_ namespace;
in the cases of both the AC_SUBST and AC_MSG_ERROR macros, which are
standard autoconf macros, and *definitely* provided in the MinGW
implementation, this is certainly the most likely cause of your error.

In the case of PKG_CHECK_MODULES, we do not provide pkg-config, so you
will need to furnish this independently; we have no plans to support it. 
However, the fragment of the error message which you do show does provide
evidence of improper quoting -- it should be 'PKG_CHECK_MODULES([GST],',
and not simply 'PKG_CHECK_MODULES(GST,'.  While this improper quoting may
not seem significant in this particular case, you should develop the habit
of always quoting correctly, to avoid errors such as you report when it
becomes significant.
Please refer to the autoconf manual for guidance.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3079289&group_id=2435



------------------------------

Message: 3
Date: Wed, 10 Nov 2010 14:02:51 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3106671 ] trivial header
	fixups
To: noreply@sourceforge.net
Message-ID: <E1PGBGF-0002hk-CB@sfs-web-10.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Patches item #3106671, was opened at 2010-11-10 15:02
Message generated for change (Tracker Item Submitted) made by jonnyh33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3106671&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johann Hanne (jonnyh33)
Assigned to: Nobody/Anonymous (nobody)
Summary: trivial header fixups

Initial Comment:
While trying to compile pywin32 (win32 API bindings for Python) with gcc/mingw I \
found some issues in the w32api headers which are easily fixed. All the information \
is available on MSDN.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3106671&group_id=2435



------------------------------

Message: 4
Date: Thu, 11 Nov 2010 11:01:51 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3107222 ] Missing structs in
	psapi.h
To: noreply@sourceforge.net
Message-ID: <E1PGUud-0001af-L2@sfs-web-5.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Bugs item #3107222, was opened at 2010-11-11 12:01
Message generated for change (Tracker Item Submitted) made by thomas-denk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3107222&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: thomas (thomas-denk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing structs in psapi.h

Initial Comment:
The QueryWorkingSet function is present, but the following associated structs are \
missing:

typedef union _PSAPI_WORKING_SET_BLOCK
{
  ULONG_PTR Flags;
  struct {
    ULONG_PTR Protection  :5;
    ULONG_PTR ShareCount  :3;
    ULONG_PTR Shared      :1;
    ULONG_PTR Reserved    :3;

	#ifdef _WIN64
    ULONG_PTR VirtualPage :52;
	#else
    ULONG_PTR VirtualPage :20;
    #endif
  } ;
} PSAPI_WORKING_SET_BLOCK, *PPSAPI_WORKING_SET_BLOCK;


typedef struct _PSAPI_WORKING_SET_INFORMATION
{
  ULONG_PTR NumberOfEntries;
  PSAPI_WORKING_SET_BLOCK WorkingSetInfo[1];
} PSAPI_WORKING_SET_INFORMATION, *PPSAPI_WORKING_SET_INFORMATION;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3107222&group_id=2435



------------------------------

Message: 5
Date: Mon, 15 Nov 2010 11:36:34 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3109481 ]
	mingw-get-inst-20101030.exe	fails to install Objective-C
To: noreply@sourceforge.net
Message-ID: <E1PHxMQ-0005AO-SA@sfs-web-6.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Bugs item #3109481, was opened at 2010-11-15 13:36
Message generated for change (Tracker Item Submitted) made by malzan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3109481&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW Installer
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael (malzan)
Assigned to: Nobody/Anonymous (nobody)
Summary: mingw-get-inst-20101030.exe fails to install Objective-C

Initial Comment:
mingw-get-inst-20101030.exe  fails to install the Objective-C binaries.
Examining  mingw32-gcc4.xml  reveals that the Objective-C section fetches  \
gcc-c++-4.5.0-1-mingw32-bin.tar.lzma. Surely this entry should point to  \
gcc-objc-4.5.0-1-mingw32-bin.tar.lzma. mingw32-gcc4.xml.lzma, in the  Home / \
Automated MinGW Installer / mingw-get / catalogue  directory, also contains this \
'wrong?' entry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3109481&group_id=2435



------------------------------

Message: 6
Date: Sat, 20 Nov 2010 19:24:44 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3113782 ] Define INT8, UINT8,
	INT16,	and UINT16
To: noreply@sourceforge.net
Message-ID: <E1PJt3E-00018P-Gz@sfs-web-5.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Patches item #3113782, was opened at 2010-11-20 14:24
Message generated for change (Tracker Item Submitted) made by sethj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3113782&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seth Jackson (sethj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Define INT8, UINT8, INT16, and UINT16

Initial Comment:
INT8, UINT8, INT16, and UINT16 are missing from basetsd.h.
This patch fixes that.

Source: http://msdn.microsoft.com/en-us/library/aa505945.aspx

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3113782&group_id=2435



------------------------------

Message: 7
Date: Sat, 20 Nov 2010 21:13:07 +0000
From: SF/projects/mingw notification list
	<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Patches-3081421 ] Allow inherited
	error mode.
To: noreply@sourceforge.net
Message-ID: <E1PJuk7-0001Jw-PL@sfs-web-8.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

Patches item #3081421, was opened at 2010-10-05 08:21
Message generated for change (Comment added) made by cstrauss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3081421&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Peter Rosin (pekberg)
Assigned to: Cesar Strauss (cstrauss)
Summary: Allow inherited error mode.

Initial Comment:
Hi!

I am a libtool developer and I have grown *real* tired of the popups displayed
when the libtool testsuite is running.  Libtool tries various things that is
supposed to not work, such as running programs with missing dlls.  That
of course triggers a tiresome popup which you have to dismiss. Every time.
So, I thought that it would be neat if you could set the error mode to something
that is not the default, and have that error mode propagate to all child
processes. This patch is what I came up with.  I know that I'm touching parts
of the code that are considered scary, and I'm a bit of a newbie msys/cygwin
hacker so there might easily be better ways to do this.  But it works for me,
and I don't think it's going to affect the normal case.

The only thing I can think of is a system with a defalt error mode that
includes the SEM_FAILCRITICALERRORS flag, but the only thing that will
happen on those systems is that whatever error mode happes to be
active when entering msys is going to be inherited to all children. But it
would be a rare case indeed if that would not be the default error mode.
That, and msys is going to be running with that error mode and not with
only SEM_FAILCRITICALERRORS (since msys drops all (non-sticky) flags
but that one without this patch).

In order to actually trigger this patch, I'm using the error-mode.c
program, which I intend to attach next.

Cheers,
Peter

----------------------------------------------------------------------

> Comment By: Cesar Strauss (cstrauss)
Date: 2010-11-20 19:13

Message:
Sorry for taking so long.

Before going forward with Peter's patch, I would like to suggest another
approach.

How about we simply stop forcing the error mode and always inherit the
error mode for child processes? In other words, drop the existing
SetErrorMode call and the CREATE_DEFAULT_ERROR_MODE flag for CreateProcess
(see attached patch). I tried it and could not see any difference in MSYS
behavior arising from the lack of the SEM_FAILCRITICALERRORS error mode at
runtime.

Regards,
Cesar


----------------------------------------------------------------------

Comment By: Charles Wilson (cwilso11)
Date: 2010-10-25 15:48

Message:
FWIW, I ran into the old "fork: blah blah" problem with MSYS-1.0.16 on my
w64 box. However...I found two ways to fix it:

#1) Use C:\Windows\SysWOW64\cmd.exe instead of 'cmd.exe', and launch the
bat file "by hand", or...

#2) Use the error_mode program to launch the bat file (this doesn't
require a patched msys dll; you don't even need to specify any of
error_mode's arguments). The reason this works is (I think) because
error_mode launches the target using _execvp, which under the hood runs
CreateProcess in such a way that the stack is in the "good location".  This
old post:
http://osdir.com/ml/gnu.mingw.msys/2004-03/msg00035.html
suggests that on w64, the memory layout of an app launched directly by the
windows system (using Nt* or z* functions rather than normal w32api ones?) 
*differs* from that of an app launched via CreateProcess (???).  So, by
ensuring that our "top level" msys app was also launched via create process
(indirectly, by way of execvp), our eventual parent process will have the
same memory layout as any of its children.

I bring this up, because once Peter's patch is merged (and error_mode.exe
is shipping in msys-1.0.nn), we'll have another thing to suggest that
people try, if they run into fork blah blah errors with msys on w64.

----------------------------------------------------------------------

Comment By: Peter Rosin (pekberg)
Date: 2010-10-20 12:09

Message:
Hi Cesar,

Godd to hear, my fingers was itching with the desire to ping this patch,
but now I
know it has been seen which makes me relax.  For a while :-)

FWIW, I've been running with it since I created it with no ill effects
that I can spot.
But I stopped trying to stress it when I was satisfied with it so that is
perhaps not
definitive.  And I don't expect you to take my word for it either...

Cheers,
Peter


----------------------------------------------------------------------

Comment By: Cesar Strauss (cstrauss)
Date: 2010-10-20 07:16

Message:
Dear Peter,

Thanks for the patch, it looks interesting.

I'll try to find some time to test it properly.

Thanks,
Cesar


----------------------------------------------------------------------

Comment By: Peter Rosin (pekberg)
Date: 2010-10-05 08:25

Message:
Oh, I forgot to mention that this error-mode program must be compiled
as a MinGW program, and not an MSYS program.  If it's an MSYS program,
the exec call will restore the default error mode before the new process
is started.

Here's the help text:
Usage: error-mode [options] [program [program options]]
  -c, --no-critical-fail       No critical failure error box
  -g, --no-general-protection  No general fault error box
  -f, --no-file-open           No open file error box
  -m MODE, --mode=MODE         Desired SetErrorMode argument
  -h, --help                   Print this message and exit
  -v, --version                Print the version number and exit

Example:
  error-mode -cgf C:/mingw/msys/1.0/msys.bat

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3081421&group_id=2435



------------------------------

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev

------------------------------

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


End of MinGW-notify Digest, Vol 54, Issue 4
*******************************************


[prev in list] [next in list] [prev in thread] [next in thread]