[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify Digest, Vol 72, Issue 10
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2012-05-20 0:16:25
Message-ID: mailman.104306.1337472985.5295.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-Bugs-3391275 ] TEMP env var is corrupted when running
external app (SF/projects/mingw notification list)
2. [ mingw-Feature Requests-3527590 ] want new heap management
(SF/projects/mingw notification list)
3. [ mingw-Bugs-3527915 ] getaddrinfo is supported from windows
2000 (SF/projects/mingw notification list)
4. [ mingw-Bugs-810393 ] windres crashes on XP when using pipes
(SF/projects/mingw notification list)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 May 2012 11:07:24 -0700
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3391275 ] TEMP env var is
corrupted when running external app
To: SourceForge.net <noreply@sourceforge.net>
Message-ID:
<mailman.104307.1337472985.5295.mingw-notify@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Bugs item #3391275, was opened at 2011-08-13 22:20
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3391275&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: Known Feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orgad Shaneh (orgads)
Assigned to: Cesar Strauss (cstrauss)
Summary: TEMP env var is corrupted when running external app
Initial Comment:
On my machine, TEMP environment variable is defined as 'D:\Temp'.
When I run msys, 'echo $TEMP' gives '/tmp', and 'msysmnt' shows that D:\Temp is \
mounted on /tmp. That's fine.
When I run an external application from msys, the TEMP variable is modified to \
'D:/Temp'.
To reproduce: Run msys, from it, run cmd /c "echo %TEMP%"
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2012-05-16 11:07
Message:
I've just looked at the patch. It appears to be barking at the wrong tree.
Have you built MSYS in debug mode? If so, strace should give you a value
for 'returning: %s'.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2012-05-16 07:30
Message:
Looks better now. Please review.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2012-05-16 07:08
Message:
Ok, this patch is still bad. It fixes the TEMP issue, but introduces new
problems. Now environment vars that were set during the session are getting
a prefix of PWD. grrr...
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2012-05-16 02:30
Message:
Ok, that's really strange. Running cmd /c "echo %TEMP%" indeed prints it
with forward slashes, but replacing cmd with cmd.exe does print it with
native slashes (with my patch).
Tried with ActivePerl, it prints forward slashes.
Any ideas?
----------------------------------------------------------------------
Comment By: Cesar Strauss (cstrauss)
Date: 2012-03-15 18:03
Message:
Sorry, your patch doesn't work for me. After applying it, I still get:
$ cmd /c "echo %TEMP%"
C:/Users/cstrauss/AppData/Local/Temp
Earlier, I intended to investigate this further, but ran out of time.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2012-03-14 00:55
Message:
?
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-19 04:22
Message:
Thanks a lot for your help. I really appreciate it.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-19 04:13
Message:
> I couldn't attach the file because the issue was closed...
I thought the ticket originator could do that, or at least reopen the
ticket to progress it. Maybe I'm wrong on that; as administrator, I have
more extensive privileges.
> Thanks for doing that.
NP. Thanks also for the tentative ChangeLog. For future reference:
- There's no need to post the whole file; just the entry to add suffices.
- Your entry should identify each modified file, and function/macro/entity
within it, as appropriate; format is defined by the GNU Coding Standards.
- You may include this within the patch file itself, but NOT as part of the
patch proper, (i.e. not in diff format).
- Normally, the maintainer will adjust the date, to reflect when he applies
the patch; thus, it's permissable to fill the date field with query marks.
I've attached an updated patch, (recreated using 'hg diff -p >> patchfile',
where patchfile initially contains the ChangeLog addendum, having applied
your original patch to a local mercurial repository copy of the pertinent
file, in its correct path from the MSYS CVS), to illustrate the concept.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-18 04:25
Message:
You're welcome.
I couldn't attach the file because the issue was closed... Thanks for doing
that.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-18 04:11
Message:
Thanks for the patch.
Attaching it to the ticket would have been infinitely preferable to posting
it on pastebin. Never mind: on this occasion only, I've done that for you.
Please do it yourself for any future patches you may wish to submit.
Adding your own ChangeLog entry would also be appreciated. If you wait for
us to write it, processing of your patch may be delayed.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-18 00:26
Message:
Ok, I prepared one. http://pastebin.com/Xm3DD6bq
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-17 13:27
Message:
> Like I said, that's what I did and it does work, but this is a
workaround,
> not a solution. ... I would prefer for it to be fixed.
So, fix it, and submit a patch; it's open source, and you have an equal
right to anyone else, (and perhaps more incentive in this case), to
contribute to development and maintenance.
For the record, according to MSDN, and with a few excepted contexts,
d:/temp is just as acceptable as a Windows path name as is d:\temp; any
application which doesn't accept it as such, other than in the excepted
contexts, is simply broken. Unfortunately, there are just so many
applications in this broken class that it probably would be preferable if
MSYS favoured '\' rather than '/' as the directory separator, when
expressing a path name in Windows native format.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 13:09
Message:
Like I said, that's what I did and it does work, but this is a workaround,
not a solution.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 12:48
Message:
If you modify the TEMP variable in the MSYS shell to be D:\TEMP it will
spawn the native environment with that value instead of D:/TEMP. And MSYS
doesn't care either. So you can set the value in your .profile file to be
the value with the \.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 12:43
Message:
I did something similar, but I would prefer for it to be fixed.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 12:41
Message:
A work around may be to edit your $HOME/.profile file and add
export TEMP='D:\TEMP'
as a command in your environment setup.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 12:41
Message:
That's exactly what I described in the first place. Thank you for
elaborating.
----------------------------------------------------------------------
Comment By: Andrew (guln)
Date: 2011-08-17 12:38
Message:
> From my brief look at this issue, it appears that when Windows' cmd.exe is
run from an MSYS environment, it is inheriting the MSYS shell's environment
variables (which I would expect). However, it looks like only the PATH
environment variable gets its slashes converted to the proper convention (/
for MSYS, \ for Windows).
For example: Spawning cmd.exe from an MSYS bash shell and running "set"
shows my TEMP environment variable as C:/Users/Username/AppData/Local/Temp,
while the PATH is correctly converted to C:\msys\mingw\bin;C:\msys\bin; et
cetera.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 06:11
Message:
Rational perl (part of ClearCase) C:\Program
Files\Rational\Common\ratlperl.exe.
The error message is 'A file open failure occured on D:'
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 06:09
Message:
Which perl.exe is being executed?
What, if any, is the error message from isqlw?
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 05:54
Message:
The perl script runs isqlw, and some of its arguments are "-i
D:/TEMP\ForClearCase.sql -o D:/TEMP\SqlOutputQuery.txt" (The D:/Temp is
parsed by perl). isqlw fails.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 05:52
Message:
So, the perl script fails? Which perl is it running? Is the error raised
by the script itself or by perl?
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-17 05:39
Message:
cleartool is the command-line tool for Rational ClearCase, which is neither
open-source nor free. It is a (terrible!) version control system.
One of its capabilities is running 'triggers' when certain operations are
executed. In my case, when I run 'mkactivity', it runs a trigger that tests
against the DB if the activity I requested is valid. This trigger is a perl
script, and it just fails when %TEMP% has / instead of \.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-17 05:16
Message:
> I really find it hard to understand why you're trying so hard to justify
this kind of manipulation.
MSYS has been out for years and no one else has complained.
> In my case, the application I run is cleartool, which runs triggers for
some operations. Those triggers don't work because of that manipulation.
Finally!!! What is cleartool and what is it doing with triggers to cause
an issue with the value of %TEMP% using a / instead of a \? I assume this
is a command line tool that you're using in the MSYS shell. Do you have a
link to the product you're using and is it open source?
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-16 06:15
Message:
I'm not talking about running things directly from msys bash prompt. What
I'm talking about is running an external application, which expects %TEMP%
to have specific form.
In my case, the application I run is cleartool, which runs triggers for
some operations. Those triggers don't work because of that manipulation.
I just tried to show the problem using a simple example. I really find it
hard to understand why you're trying so hard to justify this kind of
manipulation. It really makes no sense to me...
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-16 05:34
Message:
Yes, it is expected behavior.
Your use of %TEMP% in the MSYS shell isn't correct. The MSYS shell will
not evaluate %TEMP% to be the value of a variable but as a literal string.
You would need to use $TEMP and as Keith has already stated, that while
some things may work it isn't expected that you will be using MSYS from
cmd.exe but instead using the MSYS shell. It is also expected that while
in the MSYS shell you use POSIX semantics instead of Windows semantics.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-15 22:03
Message:
Do you seriously suggest that msys SHOULD manipulate environment variables?
I can't see your point.
Even if my small example (I'm using ActivePerl v5.12.3) does work, is this
an expected behavior?
Here is a command that won't work as expected when run from msys:
@if %TEMP%==D:\TEMP (echo Hello) else (echo Goodbye)
If %TEMP% is set to D:\TEMP, on cmd it prints Hello, on cmd run from msys
it prints Goodbye.
Another example (from command line):
copy file.ext %TEMP%
Works on cmd, doesn't work when cmd is run from msys...
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-15 10:10
Message:
Even so, I have no issue with the sample given with either running in a
cmd.exe environment or a MSYS bash environment. I tested both the MSYS
dependent perl and the ActiveState version of perl. Therefore I've closed
the ticket but feel free to comment if you have more information.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2011-08-15 07:49
Message:
What perl are you trying to run, in your example? If it is the MSYS perl,
then you should be running it from the MSYS shell, *not* from cmd.exe.
Attempting to run *any* MSYS program from cmd.exe is an ID-ten-T user
error; such usage is unsupported.
FWIW, your example WJFFM, when correctly run using MSYS perl, invoked from
the MSYS shell prompt.
----------------------------------------------------------------------
Comment By: Orgad Shaneh (orgads)
Date: 2011-08-15 06:50
Message:
Consider the following perl script:
$TDIR=$ENV{TEMP};
$fname = "$TDIR\\hello.txt";
open (test, ">$fname");
print test "Hello\n";
close (test);
Running on cmd, NOT running under msys...
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2011-08-15 06:33
Message:
You fail to say how this affects your use of native programs? I.E.: Why
are you concerned about D:/Temp instead of D:\Temp?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3391275&group_id=2435
------------------------------
Message: 2
Date: Thu, 17 May 2012 05:55:11 -0700
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Feature Requests-3527590 ] want new
heap management
To: SourceForge.net <noreply@sourceforge.net>
Message-ID:
<mailman.104308.1337472985.5295.mingw-notify@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Feature Requests item #3527590, was opened at 2012-05-17 05:55
Message generated for change (Tracker Item Submitted) made by squallatf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=352435&aid=3527590&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
Priority: 5
Private: No
Submitted By: SquallATF (squallatf)
Assigned to: Nobody/Anonymous (nobody)
Summary: want new heap management
Initial Comment:
msys gcc can't complie big source, will get out of memory allocation error.
also program in msys can't malloc mem big than 256MB.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=352435&aid=3527590&group_id=2435
------------------------------
Message: 3
Date: Fri, 18 May 2012 08:55:05 -0700
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3527915 ] getaddrinfo is
supported from windows 2000
To: SourceForge.net <noreply@sourceforge.net>
Message-ID:
<mailman.104309.1337472985.5295.mingw-notify@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Bugs item #3527915, was opened at 2012-05-18 08:55
Message generated for change (Tracker Item Submitted) made by doursse
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3527915&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: Vincent TORRI (doursse)
Assigned to: Nobody/Anonymous (nobody)
Summary: getaddrinfo is supported from windows 2000
Initial Comment:
getaddrinfo is supported from win 2000, which version is 0x0500. See
http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520%28v=vs.85%29.aspx
Earnie said that in mingw headers, this function is guarded by WINVER = 0x0501.
Maybe other functions like getaddrinfo should be cheked too.
Vincent Torri
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3527915&group_id=2435
------------------------------
Message: 4
Date: Sat, 19 May 2012 17:16:24 -0700
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-810393 ] windres crashes on XP
when using pipes
To: SourceForge.net <noreply@sourceforge.net>
Message-ID:
<mailman.104310.1337472985.5295.mingw-notify@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Bugs item #810393, was opened at 2003-09-21 21:19
Message generated for change (Comment added) made by erdizz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=810393&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: Later
Priority: 5
Private: No
Submitted By: Justin Forest (vhex)
Assigned to: Earnie Boyd (earnie)
Summary: windres crashes on XP when using pipes
Initial Comment:
windres version 2.14.90 20030612 crashes when launched
from bash with --no-use-temp-file ("windres.exe has
encountered a problem and needs to close"), with
--use-temp-file it works fine. if started from cmd.exe
or other non-msys application, it works fine. I did
not have this problem yesterday, when I was still
running win2k pro.
%%% MSYS dll major: 1000
%%% MSYS dll minor: 9
%%% MSYS dll epoch: 19
%%% MSYS dll bad signal mask: 19005
%%% MSYS dll old termios: 5
%%% MSYS dll malloc env: 28
%%% MSYS api major: 0
%%% MSYS api minor: 46
%%% MSYS shared data: 3
%%% MSYS dll identifier: cygwin1
%%% MSYS mount registry: 2
%%% MSYS cygnus registry name: msys
%%% MSYS cygwin registry name: 1.0
%%% MSYS program options name: Program Options
%%% MSYS cygwin mount registry name: mounts v2
%%% MSYS cygdrive flags: cygdrive flags
%%% MSYS cygdrive prefix: cygdrive prefix
%%% MSYS cygdrive default prefix:
%%% MSYS build date: Thu Jul 3 07:26:50 EDT 2003
%%% MSYS shared id: cygwin1S3
----------------------------------------------------------------------
Comment By: Dmitry M. Shatrov (erdizz)
Date: 2012-05-19 17:16
Message:
I found that windres crashes when COMSPEC environment variable is not set
----------------------------------------------------------------------
Comment By: Joshua Hudson (joshudson)
Date: 2004-02-28 19:03
Message:
Logged In: YES
user_id=986799
I can reproduce this bug only when MinGW is installed under
a directory in which some parent contains a space. Workaround:
use the short name in the path environment.
Looking at his environment, that is not the problem in this
case however.
----------------------------------------------------------------------
Comment By: Justin Forest (vhex)
Date: 2003-09-22 13:59
Message:
Logged In: YES
user_id=664367
Both msys and native views of the environment follow. I
have basically reinstalled the system, so I can't tell the
exact difference, but both the environment and microsoft
native runtime libraries have changed. The exception occurs
at address 0x77c3c3b3, which I believe is msvcrt.dll (base
address 0x77c10000).
plantation$ env
PWD=/home/projects/cc/faerion-1.17.8/src
OBJDIR=/tmp/obj
!C:=C:\Program Files\Far
SCITE_HOME=x:\home\.scite
SYSTEMDRIVE=C:
RCFLAGS=--use-temp-file
COMPUTERNAME=HEX
WINDIR=C:\WINDOWS
CC=mingw32-gcc.exe
HTTP_PROXY=http://127.0.0.1:3128
PS1=plantation\$
RC=windres.exe
DEBUG=1
MACHTYPE=i686-pc-msys
EORBHOME=/usr/local/bin/eorb
OS=Windows_NT
CPATH=/usr/local/include
CLIENTNAME=Console
TEMP=/tmp
SYSTEMROOT=C:\WINDOWS
RM=rm -f
LIBRARY_PATH=/usr/local/lib
TMP=/tmp
!X:=X:\home\projects\cc\faerion-1.17.8\src
SHLVL=1
USERNAME=just
SHELL=/bin/sh
HOSTTYPE=i686
CVSROOT=:sserver:hex@localhost:/vector
CPU=i686
SESSIONNAME=Console
OSTYPE=msys
HOME=/home
TERM=cygwin
PATH=/bin:/mingw/bin:/usr/local/bin:/c/winnt/system32:/c/winnt:/c/winnt/system32
/wbem:/c/program_files/putty:/c/program_files/cvsnt:/c/program_files/nsis:/c/pro
gram_files/eorb/bin/WinNT-msdev-x86:/c/program_files/Microsoft
Visual Studio .NE
T/Vc7/bin:/c/program_files/Microsoft Visual Studio
.NET/Common7/IDE
_=/bin/env
X:\>set
ALLUSERSPROFILE=C:\Documents and Settings\All Users.WINDOWS
APPDATA=C:\Documents and Settings\just\Application Data
CLIENTNAME=Console
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=HEX
ComSpec=C:\WINDOWS\system32\cmd.exe
FARLANG=English
HOME=x:\home
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\just
HTTP_PROXY=http://127.0.0.1:3128
LOGONSERVER=\\HEX
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\cvsnt;x:\bin;x:\local\bin;x:\mingw\bin;C:\Program
Files\cvsnt
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 1 Stepping 3,
GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0103
ProgramFiles=C:\Program Files
PROMPT=$P$G
SCITE_HOME=x:\home\.scite
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\Temp
TMP=C:\Temp
USERDOMAIN=HEX
USERNAME=just
USERPROFILE=C:\Documents and Settings\just
windir=C:\WINDOWS
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2003-09-22 04:17
Message:
Logged In: YES
user_id=15438
What's in the PATH variable?
What else in the environment variables may different between
the two systems?
You've tripped a known bug, that I've not been able to
eliminate. Version 1.1.0 will not show the bug as far as
I've been able to determine. My time to work on MSYS has
shortened so the length at which I'll have a snapshot up has
lengthened.
Earnie.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=810393&group_id=2435
------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
------------------------------
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest, Vol 72, Issue 10
********************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic