Robert M. Münch | 15 Sep 15:22 2014

simplest program => unknown type name 'size_t'

Hi, I’m a bit confused and getting nuts on a very simple problem. I program C since 25 years now, so it feels a
bit dumb to ask this questions. But I’m stuck with mingw at the moment (BTW: I’m using the TDM version).

Here is my very unfancy problem / program:

#include <stddef.h>

int main(){
	return 0;
}

And I get, this error when I compile it using MSYS:

$ gcc -v test.c

Using built-in specs.
COLLECT_GCC=c:\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --build=x86_64-w64-mingw32
--enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp
--enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC
--enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs
--enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time
--with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm
--with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-2 --withbugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.8.1 (tdm64-2)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/cc1.exe -quiet -v -iprefix
(Continue reading)

georg chambert | 10 Sep 07:49 2014
Picon

Download gcc

Hi
 
is there a possibility to get a gcc installation without being online, i.e. put on a stick as files and get to other computer
 
it seems that you nowadays need to be online and use the download utility ?
 
I need ada, c, c++ compilers and the linker/loader
 
thanx for help
 
Georg
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
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
Geert Janssens | 8 Sep 22:18 2014
Picon

Building guile2 under mingw32

Hi,

 

I'm trying to build guile 2.0.11 under mingw32 on Windows, but run into some compile issues. Before I continue to spend my time on this I was wondering if others on this list had done so successfully and if so, how ?

 

Thanks,

 

Geert

 

P.S. I found a thread [1] on guile-user initiated by Eli Zaretskii from June 2013 on this very subject. It mentioned a lot of patches which may or may not have been incorporated since. It was not immediately clear to me whether he managed to successfully build guile 2 on mingw32.

 

[1] https://lists.gnu.org/archive/html/guile-user/2013-06/msg00012.html

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
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
Stefan.Falk | 5 Sep 17:08 2014

Deliver make and msys/rm with Eclipse

Sorry if you got that message twice but I got a report that the last sending failed ..
 
 
Hi folks!
 
I’m not quite sure where to ask this question but I’m writing on some kind of a custom Eclipse version which is going to need make.exe (which requires rm.exe) from the MinGW suite. My question is if this is okay regarding their licenses.
 
I’d like to deliver those tools inside the Eclipse package e.g. <Eclipse-Install>/tools/MinGW/ where those files would be located.
 
This Eclipse version would (of course) be distributed in non-commercial manners.
 
Is this the right place to ask? I’m thankful for any information you can give me on this topic.
 
Thank you!
 
Best regards,
Stefan
 
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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
Keith Marshall | 29 Aug 16:24 2014
Picon
Picon

Continuing support for Windows Pre-XP in MinGW?

Folks,

If you still use Windows versions pre-dating WinXP, you need to read
this; we may not be able to offer you continuing support!

Following my recent withdrawal of the Version 4.x MinGW runtime and
w32api libraries from general release, (on account of the excessive
number of unresolved regressions which they've introduced), I've been
reviewing some of the related bug reports, with a view to backporting
some solutions to an continuation of the version 3.x series.  Three,
which I'd like to address soonest, are:
http://sourceforge.net/p/mingw/bugs/1621/ (aspect #2)
http://sourceforge.net/p/mingw/bugs/2098/
http://sourceforge.net/p/mingw/bugs/2106/

Unfortunately, the last of these raises an issue, (which I suspect is
already present with existing 3.x dirent.[hc] implementations), which
makes it increasingly difficult for us to continue supporting users of
Windows versions predating WinXP ... the _USE_32BIT_TIME_T insanity!

The problem is that we *must* provide an implementation which is
deterministically independent of the _USE_32BIT_TIME_T nonsense, so
users are not constrained by what we choose when we build libmingwex.a;
this precludes simple _findfirst()/_findnext() dependencies, and forces
us to look to _findfirst64()/_findnext64() or similar, which behave
completely independently of _USE_32BIT_TIME_T.

As I've noted on ticket #2106, the _findfirst64()/_findnext64()
combination *appears* to be the most widely acceptable; the MSDN
reference, which I cite on the ticket, suggests that this pair of
functions has been supported since Win98.  However, my own research,
(summarized at
http://sourceforge.net/projects/keithmarshall.u/files/msvcrt-xref/msvcrt.exports.pdf/download),
suggests otherwise.

Now, the solution for bug #1621 will introduce dependencies on the
dirent implementation into the mingwrt initialization code, so any
application built with this in place will likely fail on any older
version of Windows, which lacks _findfirst64()/_findnext64() support.
So, if you are a user of such a system, and you care about continuing
support from MinGW.org, you need to speak up now, (and you need to be
prepared to pitch in, and help me to develop a solution which will
continue to work for you; I have some ideas, but I cannot test their
effectiveness on anything older than WinXP).

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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

Baruch Youssin | 28 Aug 09:58 2014
Picon

Re: Which msvcrt.dll does MinGW use?

I continued this topic as a private conversation with Eli Zaretskii 
<eliz@...> as I was not sure it is worthwhile for the list.
By Eli's suggestion, I post here the entire track this far, starting 
with the old and finishing with my comments on the most recent message 
from Eli.

On 08/26/2014 04:41 PM, Baruch Youssin wrote:
> Many thanks for your prompt clarification.
> As I found this article 
>
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ 
> , I understood that indeed msvcrt.dll supplied by Windows, is updated 
> and the difference between different verstions of msvcr.. is not in 
> the standard C runtime library but rather in other MS 
> functionalities.  Thus, I understood why linking against it is the 
> best solution for MinGW.
>
> This helped me decide that the native time and time zone functions 
> provided by MS, are unreliable to the point that they should not be 
> used.  (I had one case of difftime returning the first parameter 
> instead of the difference on Windows XP SP3 under MinGW against 
> msvcrt.dll - which is not a big deal as a call to difftime under MinGW 
> can be replaced by subtracting time_t values - and another case of 
> gmtime getting the current time zone offset incorrectly on Windows 
> Server 2008 under VS2010 against msvcr100.dll.)
>
> Many thanks again
> Baruch Youssin
>
> On 08/25/2014 09:44 PM, Eli Zaretskii wrote:
>>> Date: Mon, 25 Aug 2014 21:02:38 +0300
>>> From: Baruch Youssin <quququitty@...>
>>>
>>> I am running MinGW 4.8.1 on Windows XP SP3 and could not find any
>>> msvcrt.dll or msvsrxx.dll in any MinGW directories; all versions I
>>> found, were in system directories and in the directories of other
>>> applications.
>>>
>>> So which msvcrt.dll or msvsrxx.dll does MinGW use?
>> MinGW by default links your applications against the msvcrt.dll that
>> is provided with Windows.  You can find it in the system32 directory.
>>
>> Regardless of what MS says on MSDN (which AFAIK is mainly aimed and
>> MSVC developers), you can safely use msvcrt.dll in your MinGW
>> programs.
>>
>> ------------------------------------------------------------------------------ 
>>

On 08/26/2014 05:55 PM, Eli Zaretskii wrote:
>> Date: Tue, 26 Aug 2014 16:41:49 +0300
>> From: Baruch Youssin <quququitty@...>
>> CC: Baruch Youssin <quququitty@...>
>>
>> Many thanks for your prompt clarification.
> You are welcome.
>
>> This helped me decide that the native time and time zone functions
>> provided by MS, are unreliable to the point that they should not be
>> used.
> Please post the details.  The only problems in this area that I ever
> bumped into was with the latest MinGW runtime 4.x, which attempts by
> default to use the 64-bit time_t data type and associated msvcrt
> functions, but does that in a way that trips on a few problems, and
> can easily cause application bugs.
>
> My solution is not to use MinGW runtime 4.x yet.
>
> If you use version 3.x of the runtime, please describe what problems
> you see.
>
>> (I had one case of difftime returning the first parameter instead
>> of the difference on Windows XP SP3 under MinGW against msvcrt.dll -
> Can you show a test program that reproduces the problem?
>
>> and another case of gmtime getting the current time zone offset
>> incorrectly on Windows Server 2008 under VS2010 against
>> msvcr100.dll.)
> Again, unless you use mingwrt 4.x, please consider showing the
> details.

On 08/26/2014 08:44 PM, Baruch Youssin wrote:
> Here are the details:
> I am trying to create a DLL running a simple code calling four 
> functions: time(.), gmtime(.), mktime(.) and difftime(.).  The code is 
> taken from 
> http://www.codeproject.com/Articles/144159/Time-Format-Conversion-Made-Easy 
> and is as follows:
>
>       time_t now_utc = time(0);
>       struct tm* ptm_now_UTC = gmtime(&now_utc);
>       time_t now_anti_local = mktime(ptm_now_UTC);
>       double OffsetSeconds = difftime(now_utc, now_anti_local);
>       return (int)  round(OffsetSeconds/60.0);
>
> Problem 1:
> I am running MinGW 4.8.1 on Windows XP SP3 32 bit with Eclipse 4.3.2.  
> The problem on this installation is that difftime returns its first 
> parameter instead of the difference.  This is not a big deal as MinGW 
> agrees to subtract time_t values and does it correctly.  (time_t is 
> indeed defined as __time64_t.)
> Do you think this could have been caused by MinGW?
>
> Problem 2:
> My bigger problem was an attempt to run the same code on a 64 bit 
> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against 
> its default library msvcr100.dll.  I found that difftime worked 
> correctly but gmtime went wrong: it thought the current time zone 
> offset of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours 
> due to Daylight Savings Time as my desktop correctly displayed.
>
> My feeling was that the problem at least in the second case is with 
> msvcrt rather than anything else.  Determining the current time zone 
> is known to be difficult on Windows computers, and this is what I was 
> trying to accomplish.  It appears to me that msvcrt cannot be relied 
> upon to determine the current time zone consistently, whether I use MS 
> VS or MinGW.
>
> I would appreciate any further comments.
>
> If you feel any of this should be posted, please do this.
>
> Thanks for all your help.
>
> Best regards
>
> Baruch Youssin

On 08/26/2014 09:03 PM, Eli Zaretskii wrote:
>> Date: Tue, 26 Aug 2014 20:44:08 +0300
>> From: Baruch Youssin <quququitty@...>
>> CC: Baruch Youssin <quququitty@...>
> Not sure it's a good idea to make this a private conversation.  I
> suggest to add the list back.
>
> Anyway...
>
>> I am trying to create a DLL running a simple code calling four
>> functions: time(.), gmtime(.), mktime(.) and difftime(.).  The code is
>> taken from
>> http://www.codeproject.com/Articles/144159/Time-Format-Conversion-Made-Easy
>> and is as follows:
>>
>>         time_t now_utc = time(0);
>>         struct tm* ptm_now_UTC = gmtime(&now_utc);
>>         time_t now_anti_local = mktime(ptm_now_UTC);
>>         double OffsetSeconds = difftime(now_utc, now_anti_local);
>>         return (int)  round(OffsetSeconds/60.0);
>>
>> Problem 1:
>> I am running MinGW 4.8.1 on Windows XP SP3 32 bit with Eclipse 4.3.2.
>> The problem on this installation is that difftime returns its first
>> parameter instead of the difference.
> That's not what I see here: I get the (expected) result of 180, which
> is the UTC offset in my locale.
>
>> This is not a big deal as MinGW agrees to subtract time_t values and
>> does it correctly.  (time_t is indeed defined as __time64_t.)  Do
>> you think this could have been caused by MinGW?
> That'd be my first suspicion, yes.  MinGW runtime v4.x is broken wrt
> time functions (and functions that depend on time functions, like
> 'stat' and 'findfirst').  I suggest to downgrade to mingwrt-3.20 and
> w32api-3.17, and then try again.  (You don't need to downgrade your
> GCC and Binutils, they will work with the 3.x runtime just fine.)
>
>> Problem 2:
>> My bigger problem was an attempt to run the same code on a 64 bit
>> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against
>> its default library msvcr100.dll.  I found that difftime worked
>> correctly but gmtime went wrong: it thought the current time zone offset
>> of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours due to
>> Daylight Savings Time as my desktop correctly displayed.
> Can't help you here: I don't use Studio, and don't know anything about
> how to set up time routines there.
>
>> My feeling was that the problem at least in the second case is with
>> msvcrt rather than anything else.
> I doubt that.  MinGW programs use msvcrt as well, and yet your test
> program works for me here.
>
>> Determining the current time zone is known to be difficult on
>> Windows computers
> ??? I don't find it difficult at all.  E.g., try the %z format in
> strftime.
>
>> It appears to me that msvcrt cannot be relied upon to determine the
>> current time zone consistently, whether I use MS VS or MinGW.
> That's definitely not true.  Modern Windows systems have a detailed
> database of time-zone information in their Registry, and the msvcrt
> functions are perfectly capable of using that information.
-----------------------------
My comments:

>> Problem 1:
>> I am running MinGW 4.8.1 on Windows XP SP3 32 bit with Eclipse 4.3.2.
>> The problem on this installation is that difftime returns its first
>> parameter instead of the difference.
> That's not what I see here: I get the (expected) result of 180, which
> is the UTC offset in my locale.
I presume that you have been running MinGW 4.8.1 to test this.  If so, 
it seems to me that the difference between your installation and mine is 
in msvcrt that comes with the OS.  Hence, my problem here is not with 
MinGW but rather with msvcrt.

>> Problem 2:
>> My bigger problem was an attempt to run the same code on a 64 bit
>> machine: I tried it on a Windows Server 2008 64 bit in VS 2010 against
>> its default library msvcr100.dll.  I found that difftime worked
>> correctly but gmtime went wrong: it thought the current time zone offset
>> of Jerusalem was 2 hours (GMT+2) while in fact it was 3 hours due to
>> Daylight Savings Time as my desktop correctly displayed.
> Can't help you here: I don't use Studio, and don't know anything about
> how to set up time routines there.
As far as I see, the time routines are part of the standard run-time 
library and need not be set up in any way.  They are supposed to work 
correctly when called.  If they do not, they cannot be relied upon.  
Since there is no reason to assume that msvcrt is consistently better 
than msvcr100, it cannot be relied upon either.

>> My feeling was that the problem at least in the second case is with
>> msvcrt rather than anything else.
> I doubt that.  MinGW programs use msvcrt as well, and yet your test
> program works for me here.
As I wrote above, your msvcrt may be different from mine, and this seems 
to me to be the only reason for the difference in behavior.

>> Determining the current time zone is known to be difficult on
>> Windows computers
> ??? I don't find it difficult at all.  E.g., try the %z format in
> strftime.
On my Windows XP Mingw4.8.1 Eclipse 4.3.2 computer %z format in strftime 
returns the same thing as %Z format: "Jerusalem Daylight Time".  It does 
not return +300 expected.  This is in agreement with 
http://msdn.microsoft.com/en-us/library/fe06s4ak.aspx .  I guess MS has 
not yet implemented C99 in which %z belongs.

>> It appears to me that msvcrt cannot be relied upon to determine the
>> current time zone consistently, whether I use MS VS or MinGW.
> That's definitely not true.  Modern Windows systems have a detailed
> database of time-zone information in their Registry, and the msvcrt
> functions are perfectly capable of using that information.
Java has had trouble determining the current time zone on Windows 
machines for many years (since 2000?).  Bugs have been filed with Sun 
and Oracle and rejected as unreproducible.  You can read about this 
here: 
http://techtavern.wordpress.com/2010/04/15/java-and-incorrect-timezone-on-windows-xp/
This article also explains what happens in the Registry so that it 
cannot be reliably used to find out the correct time zone info.
There are plenty other similar complaints on the net.
Just six months ago, in the beginning of 2014, Java on my own Windows XP 
reported the current time zone as America/Bahia instead of 
Asia/Jerusalem; an update from Java has fixed this recently.
And my experience with Windows Server 2008 that has gmtime erring in the 
current offset shows that msvcr.. is not reliable either.

Best regards

Baruch

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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

Thomas Martitz | 27 Aug 09:14 2014

Plugins on win32

Hello,

my name is Thomas and I'm a computer scientist from Berlin, working in 
the embedded industry. In my spare time I work in the Geany IDE and Rockbox.

I'm struggling to make plugins on win32 work (for Geany), using dll 
import/export mechanism. The following two files display my case:

--- main.c i586-mingw32msvc-gcc main.c -o main
#include <windows.h>
#include <stdio.h>

__declspec(dllexport)
void foo(const char *s)
{
     printf("%s\n", s);
}

int main()
{
     void *p = LoadLibrary("plugin.dll");

     void (*fn)() = (void *)GetProcAddress(p, "plugin_func");

     fn();

     return 0;
}

--- plugin.c i586-mingw32msvc-gcc -shared -Wl,--dll 
-Wl,--allow-shlib-undefined -Wl,--enable-auto-import plugin.c -o plugin.dll
#include <stdio.h>

__declspec(dllimport)
void foo(const char *s);

void plugin_func()
{
     foo("plugin");
}

When compiling the plugin I get:
/tmp/ccncPmiG.o:plugin.c:(.text+0xf): undefined reference to `__imp__foo'
collect2: ld returned 1 exit status

I assume this is the expected behavior. So now my question is how to 
make this work? On linux it "just works" because shared libraries can 
have undefined symbols, which are resolved to the main binary symbols 
when the library is loaded. For Win32, I cannot make the linker succeed, 
even with --enable-auto-import or --allow-shlib-undefined.

Can you please give me advice on how to resolve my issue? Many thanks in 
advance

Best regards

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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 | 26 Aug 11:52 2014
Picon

rsync.exe: *** Couldn't reserve space for cygwin's heap (0x71110000 <0x5D0000>) in child, Win32 error 0

Hello,

I have installed MSYS on a new machine running Windows 7 64bit. I have manually installed rsync.exe and all
the dll needed by it.

Now when I type `rsync.exe --help' I get the following message:

-----------------------------------
m.AllocationBase 0x0, m.BaseAddress 0x71110000, m.RegionSize 0xF0000, m.State 0x10000
C:\Nos_Programmes\msys\bin\rsync.exe: *** Couldn't reserve space for cygwin's heap (0x71110000
<0x5D0000>) in child, Win32 error 0
-----------------------------------

`env' give the following output:
-----------------------------------
HOMEPATH=\
APPDATA=C:\Users\Administrateur\AppData\Roaming
PROGRAMW6432=C:\Program Files
TERM=cygwin
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel
WINDIR=C:\Windows
COMMONPROGRAMW6432=C:\Program Files\Common Files
PUBLIC=C:\Users\Public
OLDPWD=/usr/bin
PROGRAMDATA=C:\ProgramData
USERDOMAIN=AIGLEROYAL
COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files
OS=Windows_NT
ALLUSERSPROFILE=C:\ProgramData
TEMP=/tmp
COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files
USERNAME=Administrateur
MOZ_PLUGIN_PATH=C:\Program Files (x86)\Foxit Software\Foxit
Reader\plugins\
PROCESSOR_LEVEL=6
PATH=.:/usr/local/bin:/mingw/bin:/bin:/perl/site/bin:/perl/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Programmes/MikTeX
2.9/miktex/bin/:/c/Program Files (x86)/PDFtk/bin/:/c/Program Files
(x86)/Bazaar:/c/Programmes/MiKTeX 2.9/miktex/bin/x64/:/c/Nos_Programmes/cwRsync_5.3.0_Free:/bin:/mingw/bin
PSMODULEPATH=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
MSYSCON=sh.exe
FP_NO_HOST_CHECK=NO
PWD=/bin
SYSTEMDRIVE=C:
PROCESSOR_ARCHITEW6432=AMD64
USERPROFILE=C:\Users\Administrateur
PS1=\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u <at> \h \[\033[33m\w\033[0m\]
$ 
LOGONSERVER=\\AIGLEROYAL
PROCESSOR_ARCHITECTURE=x86
LOCALAPPDATA=C:\Users\Administrateur\AppData\Local
!C:=C:\Nos_Programmes\msys\bin
HOME=/home/Administrateur
SHLVL=1
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY
HOMEDRIVE=C:
WINDOWS_TRACING_FLAGS=3
WINDOWS_TRACING_LOGFILE=C:\BVTBin\Tests\installpackage\csilogfile.log
PROMPT=$P$G
MSYSTEM=MINGW32
COMSPEC=C:\Windows\SysWOW64\cmd.exe
LOGNAME=Administrateur
TMP=/tmp
SYSTEMROOT=C:\Windows
PROCESSOR_REVISION=2a07
MAKE_MODE=unix
PROGRAMFILES=C:\Program Files (x86)
NUMBER_OF_PROCESSORS=4
PROGRAMFILES(X86)=C:\Program Files (x86)
SESSIONNAME=Console
HISTFILE=/home/Administrateur/.bash_history
COMPUTERNAME=AIGLEROYAL
_=./env
-----------------------------------

Any clue how to get it working is welcome.

   Vincent.

 		 	   		  
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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

sogand | 26 Aug 11:08 2014
Picon

a problem with Msys

I have a problem with msys
Here is the picture of my msys:

https://dl.dropboxusercontent.com/u/46683290/server%20error.JPG

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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

Baruch Youssin | 25 Aug 20:02 2014
Picon

Which msvcrt.dll does MinGW use?

The page at http://www.mingw.org/wiki/C99 says: "The MinGW port of GCC 
uses Microsoft's original (old) Visual C runtime, MSVCRT, which was 
targeted by Microsoft Visual Studio 6 (released in 1998)."

This appears to imply that MinGW does not use the version of msvcrt.dll 
supplied by Windows OS.
This agrees with Microsoft that has been saying for a while already 
http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.71%29.aspx that 
msvcrt.dll supplied by Windows OS should not be used by user applications.

I am running MinGW 4.8.1 on Windows XP SP3 and could not find any 
msvcrt.dll or msvsrxx.dll in any MinGW directories; all versions I 
found, were in system directories and in the directories of other 
applications.

So which msvcrt.dll or msvsrxx.dll does MinGW use?

Please reply to the list as I believe the answer may be helpful to others.

Thanks
Baruch Youssin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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

Eli Zaretskii | 25 Aug 17:59 2014
Picon

Re: _wfopen in current MinGW

[Please don't make this a private discussion.]

> Date: Mon, 25 Aug 2014 07:54:59 -0700
> From: Roger Pepitone <rogerpepitone@...>
> 
> > Error message: '_wfopen' was not declared in this scope
> 
> You need to include <cstdio>.
> 
> 
> I was including <cstdio> (and stdio.h, and cwchar, and wchar.h)

Then please show a minimal complete source file that can be used to
reproduce the problem.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
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