mingw-users Mailing List for MinGW - Minimalist GNU for Windows

On Thursday 31 December 2009 17:30:59 JonY wrote:
> I thought he was using msvc "cl" to compile and link, which needs
> to be told to use libmingwex.a.

It would, IF the dependency on MinGW's enhanced printf() subsystem is 
REALLY desired.  When building a library intended for use with other 
compilers than MinGW, it may be a rash choice to introduce that 
dependency; better IMO, to understand why the dependency arises in 
the first place, and then make an informed choice on whether to keep 
it, or to eliminate it.

> Apparently, this is not the case.

No.  The clue was in the error message originally posted:

> ... In function `fprintf':
> C:/MinGW/include/stdio.h:246: undefined reference to
> `___mingw_vfprintf'
> collect2: ld returned 1 exit status 

The use of collect2 suggests a GNU tool chain, (and the reference in 
question shows us that some compilation unit in the project was 
built with compile time flags to explicitly map fprintf() to 
__mingw_fprintf(), rather than to the default __msvcrt_fprintf()).

-- 

Regards,
Keith.

On 12/31/2009 22:57, Keith Marshall wrote:
> On Thursday 31 December 2009 13:59:20 JonY wrote:
>> try adding libmingwex.a to your link command.
>
> He shouldn't need to; it should be specified automatically, if he is
> using gcc or g++ correctly for linking.
>
> I don't mean to denigrate your efforts to help, JonY, but without a
> proper understanding of *why* MinGW's enhanced printf() subsystem is
> being called, IMHO simply saying "add libmingwex.a" is poor advice
> indeed, (and FWIW, it was I who actually wrote MinGW's enhanced
> printf() subsystem).
>

Ok,

I thought he was using msvc "cl" to compile and link, which needs to be 
told to use libmingwex.a.

Apparently, this is not the case.

Thank you. The solution was to include ptw32_processInitialize() before any
pthread call.

On Thu, Dec 31, 2009 at 3:45 AM, Tor Lillqvist <tm...@ik...> wrote:

> > In addition to the GCC 4, I also downloaded this targz:
> >
> >
> https://sourceforge.net/projects/mingw/files/GCC%20Version%204/Current%20Release_%20gcc-4.4.0/pthreads-w32-2.8.0-mingw32-dll.tar.gz/download
>
> The thread is about using a *static* pthread library. The above
> tarball contains an import library for pthreadGC2.dll (which you
> apparently already had in your PATH from earlier. Check with objdump
> -p and you will notice that the executable you built links to
> pthreadGC2.dll.
>
> --tml
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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
>

On Thursday 31 December 2009 15:38:59 JC wrote:
> I am a beginner with Code Blocks and with MinGW, before I worked
> with MSVC...

That's okay; we were all be beginners once :-)

> I launch the compilation with Code Blocks 8.02, and I use
> mingw32-g++.exe to compile. I don't know how to view the link
> command generated by code blocks.

I can't help you with that, because I don't use an IDE.  Is the 
command not shown, just before the error messages it produces?

> The ___mingw_vfprintf unresolved appears when I compile my project
> with the static librairie Agar (1.3.4 compiled by me for mingw).

I guess their build system specifies compilation standards which 
would activate MinGW's enhanced printf() subsystem; since you have a 
version of mingwrt which supports this, your build of their code 
implicitly acquires that dependency.

> If I change juste the library of Agar to take the 1.3.3 compiled
> by the Agar team for mingw I don't have this error. 

Perhaps they built that against an earlier version of mingwrt, which 
didn't have the enhanced printf() support, (or they took precautions 
to disable it, but then why didn't they incorporate such precautions 
into their published build system)?

> Like you proposed, I have tried to had libmingwex to my link
> settings but I ever have the same unresolved reference. I think
> it's the Agar 1.3.4 library compiled by me wich needs stdio.h but
> I don't know why. 

Most projects, (those which read and write file streams), require 
stdio.h; it's a standard system header, provided by MinGW in mingwrt.  
From mingwrt-3.15 onward, stdio.h has included conditional defines 
to activate the enhanced printf() subsystem, but not by default; it 
is only under specific circumstances as described in...

> I looked for "_mingw.h", this string doesn't appear in my project
> and also doesn't appear in the agar project.

...this system *header* file; I wouldn't expect your project, or any 
other, to refer to it directly, (indeed it would be wrong if it did), 
but it is implicitly included automatically by every MinGW compile.

Your issue isn't associated with stdio.h per se; it is why the 
standard set of system libraries, with libmingwex.a among them, are 
not being included in the linking phase of your project build.  You 
shouldn't need to add any of these libraries explicitly; they should 
all be specified automatically, by gcc or g++ when they are invoked 
to link the executable; if not, then there is something wrong with 
your project build system.  To help you resolve that, you should 
either remove the IDE from the equation, and learn how to use the 
compiler tools directly, or ask for advice on a Code::Blocks mailing 
list or forum.

-- 

Regards,
Keith.

I found in the Agar source code (the library wich I use) the file "file_dlg.c" uses the fprintf function from stdio.h. So it seems it's normal to add the link dependancy "libmingwex". Isn't it ? But when I add this link dependancy I still have the same error.




________________________________
De : JC <ah...@ya...>
À : MinGW Users List <min...@li...>
Envoyé le : Jeu 31 Décembre 2009, 16 h 38 min 59 s
Objet : [Mingw-users] Re : undefined reference with ___mingw_vfprintf


Ok, I thank this would be enough information for an undefined reference problem.

I am a beginner with Code Blocks and with MinGW, before I worked with MSVC...

I launch the compilation with Code Blocks 8.02, and I use mingw32-g++.exe to compile. I don't know how to view the link command generated by code blocks.

The ___mingw_vfprintf unresolved appears when I compile my project with the static librairie Agar (1.3.4 compiled by me for mingw). If I change juste the library of Agar to take the 1.3.3 compiled by the Agar team for mingw I don't have this error.
 
Like you proposed, I have tried to had libmingwex to my link settings but I ever have the same unresolved reference. I think it's the Agar 1.3.4 library compiled by me wich needs stdio.h but I don't know why.
 
I looked for "_mingw.h", this string doesn't appear in my project and also doesn't appear in the agar project.
 a+
J-C 




________________________________
De : Keith Marshall <kei...@us...>
À : min...@li...
Envoyé le : Jeu 31 Décembre 2009, 15 h 57 min 34 s
Objet : Re: [Mingw-users] undefined reference with ___mingw_vfprintf

On Thursday 31 December 2009 13:59:20 JonY wrote:
> try adding libmingwex.a to your link command.

He shouldn't need to; it should be specified automatically, if he is 
using gcc or g++ correctly for linking.

I don't mean to denigrate your efforts to help, JonY, but without a 
proper understanding of *why* MinGW's enhanced printf() subsystem is 
being called, IMHO simply saying "add libmingwex.a" is poor advice 
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced 
printf() subsystem).

-- 

Regards,
Keith.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
MinGW-users mailing list
Min...@li...

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


      

Ok, I thank this would be enough information for an undefined reference problem.

I am a beginner with Code Blocks and with MinGW, before I worked with MSVC...

I launch the compilation with Code Blocks 8.02, and I use mingw32-g++.exe to compile. I don't know how to view the link command generated by code blocks.

The ___mingw_vfprintf unresolved appears when I compile my project with the static librairie Agar (1.3.4 compiled by me for mingw). If I change juste the library of Agar to take the 1.3.3 compiled by the Agar team for mingw I don't have this error.
 
Like you proposed, I have tried to had libmingwex to my link settings but I ever have the same unresolved reference. I think it's the Agar 1.3.4 library compiled by me wich needs stdio.h but I don't know why.
 
I looked for "_mingw.h", this string doesn't appear in my project and also doesn't appear in the agar project.
 a+
J-C 




________________________________
De : Keith Marshall <kei...@us...>
À : min...@li...
Envoyé le : Jeu 31 Décembre 2009, 15 h 57 min 34 s
Objet : Re: [Mingw-users] undefined reference with ___mingw_vfprintf

On Thursday 31 December 2009 13:59:20 JonY wrote:
> try adding libmingwex.a to your link command.

He shouldn't need to; it should be specified automatically, if he is 
using gcc or g++ correctly for linking.

I don't mean to denigrate your efforts to help, JonY, but without a 
proper understanding of *why* MinGW's enhanced printf() subsystem is 
being called, IMHO simply saying "add libmingwex.a" is poor advice 
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced 
printf() subsystem).

-- 

Regards,
Keith.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
MinGW-users mailing list
Min...@li...

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



      

On Thursday 31 December 2009 13:59:20 JonY wrote:
> try adding libmingwex.a to your link command.

He shouldn't need to; it should be specified automatically, if he is 
using gcc or g++ correctly for linking.

I don't mean to denigrate your efforts to help, JonY, but without a 
proper understanding of *why* MinGW's enhanced printf() subsystem is 
being called, IMHO simply saying "add libmingwex.a" is poor advice 
indeed, (and FWIW, it was I who actually wrote MinGW's enhanced 
printf() subsystem).

-- 

Regards,
Keith.

On Thursday 31 December 2009 13:29:42 JC wrote:
> I have a problem an undefined reference with ___mingw_vfprintf. Do
> somebody knows where it could come from please ?

You don't provide anywhere near enough information for us to be able 
to say, but there are two or more issues here (see below).

> Here are my compilation log :

What is the command which was run, to generate this?  (The actual 
command invoked *by* the makefile, or build script, as appropriate).
 
> -------------- Build: Debug in jkt2010 ---------------
> Linking console executable: bin\Debug\jkt2010.exe
> Libs\agar-1.3.4-recompile\lib/libag_gui_static.a(file_dlg.o): In
> function `fprintf': C:/MinGW/include/stdio.h:246: undefined
> reference to `___mingw_vfprintf' collect2: ld returned 1 exit
> status
> Process terminated with status 1 (0 minutes, 2 seconds)
> 1 errors, 0 warnings

This was raised previously a couple of weeks ago, but I don't believe 
it was ever adequately answered.  There are at least two issues here:

1) Why is this symbol being referenced in the first place?  Unless 
you request MinGW's enhanced printf() support, either explicitly, or 
implicitly by specifying a compilation standard which requires it, 
(see _mingw.h in the system include directory), then this symbol 
should not be referenced at all.

2) If you understand why it is required, and believe it correct that 
it is, then you need to determine why the appropriate library is not 
being included in the link; (this is why it is important for you to 
show us the linking command).  The missing symbol is defined in 
libmingwex.a, from mingwrt version 3.15 onward, (and your stdio.h 
*must* be from a conforming release for the reference to appear at 
all); the issue is why is that library not searched, because it is 
automatically included as a default system library, if you've 
specified the linking command correctly, (using gcc or g++, as you 
are supposed to, and *not* trying to invoke ld directly).

-- 

Regards,
Keith.

On 12/31/2009 21:29, JC wrote:
> Hello,
>
> I have a problem an undefined reference with ___mingw_vfprintf. Do somebody knows where it could come from please ? Here are my compilation log :
>
> -------------- Build: Debug in jkt2010 ---------------
> Linking console executable: bin\Debug\jkt2010.exe
> Libs\agar-1.3.4-recompile\lib/libag_gui_static.a(file_dlg.o): In function `fprintf':
> C:/MinGW/include/stdio.h:246: undefined reference to `___mingw_vfprintf'
> collect2: ld returned 1 exit status
> Process terminated with status 1 (0 minutes, 2 seconds)
> 1 errors, 0 warnings
>
>
> Best regards
>

Hi,

try adding libmingwex.a to your link command.

Hello,

I have a problem an undefined reference with ___mingw_vfprintf. Do somebody knows where it could come from please ? Here are my compilation log :

-------------- Build: Debug in jkt2010 ---------------
Linking console executable: bin\Debug\jkt2010.exe
Libs\agar-1.3.4-recompile\lib/libag_gui_static.a(file_dlg.o): In function `fprintf':
C:/MinGW/include/stdio.h:246: undefined reference to `___mingw_vfprintf'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 0 warnings


Best regards


      

 > > Anyone any idea how I write a simple console application that actually
 > > workes on console window in XP ?

My old conio package should still work, download at: 
http://users.ncrvnet.nl/gmvdijk/packages.html#CONSOLE

Spec:

package NT_Console is

   ----------------------
   -- TYPE DEFINITIONS --
   ----------------------

   subtype X_Pos is Natural range 0 .. 79;
   subtype Y_Pos is Natural range 0 .. 24;

   type Color_Type is
     (Black, Blue, Green, Cyan, Red, Magenta, Brown, Gray,
      Light_Blue, Light_Green, Light_Cyan, Light_Red,
      Light_Magenta, Yellow, White);

   ----------------------
   -- EXTENDED PC KEYS --
   ----------------------

   Key_Alt_Escape       : constant Character := Character'Val (16#01#);
   Key_Control_At       : constant Character := Character'Val (16#03#);
   Key_Alt_Backspace    : constant Character := Character'Val (16#0E#);

   ...

   Key_Alt_Tab          : constant Character := Character'Val (16#A5#);
   Key_Alt_Enter        : constant Character := Character'Val (16#A6#);

   --------------------
   -- CURSOR CONTROL --
   --------------------

   function  Cursor_Visible return Boolean;
   procedure Set_Cursor (Visible : in Boolean);

   function Where_X return X_Pos;
   function Where_Y return Y_Pos;

   procedure Goto_XY
     (X : in X_Pos := X_Pos'First;
      Y : in Y_Pos := Y_Pos'First);

   -------------------
   -- COLOR CONTROL --
   -------------------

   function Get_Foreground return Color_Type;
   function Get_Background return Color_Type;

   procedure Set_Foreground (Color : in Color_Type := Gray);
   procedure Set_Background (Color : in Color_Type := Black);

   --------------------
   -- SCREEN CONTROL --
   --------------------

   procedure Clear_Screen (Color : in Color_Type := Black);

   -------------------
   -- SOUND CONTROL --
   -------------------
   procedure Bleep;

   -------------------
   -- INPUT CONTROL --
   -------------------

   function Get_Key return Character;
   function Key_Available return Boolean;

end NT_Console;

-- 
--  Jerry van Dijk
--  Leiden, Holland
--
--  The early bird may get the worm, but the second mouse gets the cheese!!

> In addition to the GCC 4, I also downloaded this targz:
>
> https://sourceforge.net/projects/mingw/files/GCC%20Version%204/Current%20Release_%20gcc-4.4.0/pthreads-w32-2.8.0-mingw32-dll.tar.gz/download

The thread is about using a *static* pthread library. The above
tarball contains an import library for pthreadGC2.dll (which you
apparently already had in your PATH from earlier. Check with objdump
-p and you will notice that the executable you built links to
pthreadGC2.dll.

--tml

It doesn't seem to be very well documented, but you need to call
ptw32_processInitialize() before any other pthreads-win32 call if you
use a static pthreads-win32 library.

It is only mentioned once in the README file and is quite easy to miss
as it is mentioned under a "Other name changes" header (the function
apparently used to be called _pthread_processInitialize() a long time
ago).

--tml

On 12/31/2009 7:04 AM, Flex Flextrometer wrote:
> Here are the steps I took:
> * Compiled the pthreads library using 'make clean GC-static' command. 
> I ran the test inside tests/ and it passed.
>
> * Copied libpthreadGC2.a, pthread.h, sched.h, and sempahore.h to my 
> local source tree.
>
> * Executed the following gcc commands
>    gcc -g -UNDEBUG -Wall -D__CLEANUP_C -DPTW32_STATIC_LIB -o main.exe 
> main.c
>    -Iinclude -Llib -lpthreadGC2 -lsupc++ -lws2_32
>
>   This is the command that was executed during the test in tests/.
>
> * Ran the program and crashed if it reaches a call to pthread_create().
I am using pthread myself using the latest MinGW release from 
sourceforge (gcc4.4.0)
For me it is working great. However, note that I did not had to download 
any other libraries other than
the ones offered in the MinGW download site.

In addition to the GCC 4, I also downloaded this targz:

https://sourceforge.net/projects/mingw/files/GCC%20Version%204/Current%20Release_%20gcc-4.4.0/pthreads-w32-2.8.0-mingw32-dll.tar.gz/download

And simply extracted its content to my MinGW directory.

Building sample:

gcc -c  "C:/TestArea/pthread_sample/main.c" -g  -o ./Debug/main.o "-I."
gcc -o ./Debug/pthread_sample ./Debug/main.o  "-L."  -lpthread

Note that I am linking against 'pthread' and not against 'pthread*GC2*'

And this sample runs fine.
Eran

I'm using MinGW 5.1.6 with MSYS 1.0.11 to create an application that
utilizes pthreads. The pthread library I am using comes from
http://sourceware.org/pthreads-win32/. I understand that this is the most
common one used under MinGW. I managed to compile the pthread library and
link against it, but when the program runs, it crashes. The program I am
compiling is the first sample source from a tutorial
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html. I've
compiled it on Linux and it ran fine.

Here are the steps I took:
* Compiled the pthreads library using 'make clean GC-static' command. I ran
the test inside tests/ and it passed.

* Copied libpthreadGC2.a, pthread.h, sched.h, and sempahore.h to my local
source tree.

* Executed the following gcc commands
   gcc -g -UNDEBUG -Wall -D__CLEANUP_C -DPTW32_STATIC_LIB -o main.exe main.c

   -Iinclude -Llib -lpthreadGC2 -lsupc++ -lws2_32

  This is the command that was executed during the test in tests/.

* Ran the program and crashed if it reaches a call to pthread_create().

I tried this on two machines and the result is the same. I haven't installed
any other pthread library, so I don't think there's a conflict there.

Thank you.

On Wed, 2009-12-30 at 15:54 +0000, Keith Marshall wrote:
> On Wednesday 30 December 2009 15:28:06 Jonathan Andrews wrote:
> > I was using mingw5.1.4.exe windows package to build the exe, but I
> > dont have any more solid information.
> 
> And that much is completely nebulous; it tells us what version of the 
> installer application you used, but that in itself tells us nothing 
> about what you actually installed -- the installer payload may change 
> any arbitrary number of times during the life cycle of any particular 
> version of the installer.  All we can deduce is that gcc would have 
> come from the 3.x series, but the runtime support and binutils could 
> have been any version.
Yes, im aware of this, hence the lack of solid information. To make life
worse I also updated the service pack on the windows machine, almost
certainly replacing the crt dlls.  I just blundered blindly through it
in the hope of a resolution, in hindsight I should have preserved the
non working test case. At one point I had simple test with a kbhit that
just stalled, but know i've changed everything - test code, compiler and
windows itself...doh !.......



> > Many thanks for your time, maybe its user error on my part or some
> > weird interaction I cant reproduce :-(
> 
> Don't you just hate that class of defect?

Yep - fortunately doesn't happen often.  After 2 weeks of solid coding
its more than possible it was finger trouble on my part. Not helped by
starting off using wine for testing the exe. I did figure out wine was
broken and move onto a real windows box.....

My other hated class of defect is the sloppy pointer that often points
to RAM the process owns, but not always. Random infrequent segfault, but
never when you start the debugger first.

Cheers,
Jon

On Wednesday 30 December 2009 15:28:06 Jonathan Andrews wrote:
> I was using mingw5.1.4.exe windows package to build the exe, but I
> dont have any more solid information.

And that much is completely nebulous; it tells us what version of the 
installer application you used, but that in itself tells us nothing 
about what you actually installed -- the installer payload may change 
any arbitrary number of times during the life cycle of any particular 
version of the installer.  All we can deduce is that gcc would have 
come from the 3.x series, but the runtime support and binutils could 
have been any version.

> Under wine the windows console application never sees the keypress
> event, so just flops around the idle loop.

Note that I observed the same phenomenon.  That would indicate an 
issue with Wine, rather than with MinGW.

> Many thanks for your time, maybe its user error on my part or some
> weird interaction I cant reproduce :-(

Don't you just hate that class of defect?

-- 

Regards,
Keith.

On Wed, 2009-12-30 at 14:52 +0200, Tor Lillqvist wrote:
> Isn't the whole concept of "console" apps that still are partly "GUI"
> and "fake event driven" (polling) in the sense that they use "raw" IO,
> use kbhit() etc, a relic from MS-DOS times anyway? But I digress.
> 
> This trivial test program works fine for me, Works the same when built
> with MSVC6, MSVC9 or MinGW, and run in a console window:
> 
> #include <conio.h>
> #include <stdio.h>
> 
> int main (int argc, char **argv)
> {
>   while (!_kbhit())
>     ;
> 
>   printf ("\nYou hit '%c'\n", _getch());
>   return 0;
> }
> 
> Note that running this program loads one CPU ("core") close to 100%,
> the CPU time being spent (on Windows 7) by the program itself, the
> conhost.exe and csrss.exe processes. Is that really what you want?
> 
> > MinGW conio kbhit is bust
> 
> The kbhit() you call in MinGW -built code is in msvcrt.dll, it is not
> originating from MinGW in any way.
> 
> My guess is that your problem is caused by using rxvt. That rxvt works
> oddly is not really a MinGW problem (but yeah, I understand that it
> might be hard to see what is MinGW and what is MSYS). Using rxvt is
> really not recommended, although I can't say where on the MinGW and
> MSYS site that is said...
> 
Thanks everyone for their comments.  

I foolishy did not preserve a snapshot at the point it was blocking.  I
was using mingw5.1.4.exe windows package to build the exe, but I dont
have any more solid information. 

My application is test code for a display application, it generates UDP
broadcast packets in response to keypresses. 

Im building both linux, linux-arm and windows versions from a linux
devel machine, using mingw under wine to produce the windows binary. I
use a shell script to build everything rather than make, example:


echo -e "Compiling udptxtest.c \t\t\t -> udptxtest"
cc udptxtest.c -o udptxtest -lm

if [ "$HASCROSS" == "1" ]; then
        echo -e "Compiling udptxtest.c \t\t\t -> udptxtest-arm"
        arm-softfloat-linux-gnu-gcc udptxtest.c -static -l:"$JPLIB" -lm -o udptxtest-arm -O2 
fi

# If windows mingw package installed under wine then produce windows .exe
if [ -f $HOME/.wine/drive_c/MinGW/bin/gcc.exe ]; then
        echo -e "Compiling udptxtest.c \t\t\t -> udptxtest.exe"
        gcc.exe udptxtest.c -o udptxtest.exe -lws2_32 -D MINGW
        #if [ -f ./udptxtest.exe ]; then
                #echo "Ok, built Windows executable"
        #fi
fi


The code main loop does this ....

        // ********************************************************************************************************************************
        // Main loop, read keyboard and keep controls within limits
        while (quit!=TRUE)
        {
                // Before we start the loop take a copy of teldata
                //memcpy(&pteldata,&teldata,sizeof(struct telemetry_0x04_defs)); 	// Keep a copy for comparison later

                key=0;                                                                  // Start with the assumption of no key
                #ifdef MINGW
                if (hitkb()==0)
                        key=getch();
                #else
                // Linux
                if (kbhit()!=0)                                                         // On linux test for next key ?
                        key=getc(stdin);
                #endif

                if (key>13)
                {
                        //printf("key=%d",key); fflush(stdout);
                        if ((key=='q')|(key=='Q')) quit=TRUE;



Under wine the windows console application never sees the keypress
event, so just flops around the idle loop. 

When I started out coding it seemed to just block on kbhit in both wine
and on a real windows 2000 machine. Now I need to I cant reproduce the
behavior, but I have changed many many things including the version of
MinGW.

The test programs from yourself and Keith both work as expected on the
real windows machine.

Many thanks for your time, maybe its user error on my part or some weird
interaction I cant reproduce :-(

Cheers,
Jon

Isn't the whole concept of "console" apps that still are partly "GUI"
and "fake event driven" (polling) in the sense that they use "raw" IO,
use kbhit() etc, a relic from MS-DOS times anyway? But I digress.

This trivial test program works fine for me, Works the same when built
with MSVC6, MSVC9 or MinGW, and run in a console window:

#include <conio.h>
#include <stdio.h>

int main (int argc, char **argv)
{
  while (!_kbhit())
    ;

  printf ("\nYou hit '%c'\n", _getch());
  return 0;
}

Note that running this program loads one CPU ("core") close to 100%,
the CPU time being spent (on Windows 7) by the program itself, the
conhost.exe and csrss.exe processes. Is that really what you want?

> MinGW conio kbhit is bust

The kbhit() you call in MinGW -built code is in msvcrt.dll, it is not
originating from MinGW in any way.

My guess is that your problem is caused by using rxvt. That rxvt works
oddly is not really a MinGW problem (but yeah, I understand that it
might be hard to see what is MinGW and what is MSYS). Using rxvt is
really not recommended, although I can't say where on the MinGW and
MSYS site that is said...

--tml

On Wednesday 30 December 2009 03:13:16 Jonathan Andrews wrote:
> MinGW conio kbhit is bust,

For the record, it *isn't* MinGW's kbhit(); the implementation comes 
directly from Microsoft, via the system DLLs (MSVCRT).  Here's what 
MSDN has to say [*] about it:
http://msdn.microsoft.com/en-us/library/ms235390(VS.80).aspx
|kbhit 
|This POSIX function [?] is deprecated beginning in Visual C++ 2005.
|Use the ISO C++ conformant _kbhit instead. 

[?] Huh?  What's this all about.  AFAIK, kbhit() is not, and never 
has been a POSIX function; (it certainly doesn't get a mention in 
IEEE-1003.1.2004, the current POSIX specification, as searched by:
http://www.opengroup.org/cgi-bin/kman2?value=kbhit ).

[*] Okay, that's pertinent for the VS.2005 implementation, while the 
system MSVCRT, used by MinGW, is expected to be VS.6.0 compliant; in 
any case, deprecated doesn't mean discontinued, so we may reasonably 
expect kbhit() to exhibit the same behaviour as _kbhit(), and 
MinGW's libmoldname.a will make it so.

> cost me an entire day of pissing about 
> - maybe mingw should mention this in the notes.........

Why?  This trivial test case works perfectly [**] for me, both with 
kbhit() and with _kbhit() (as shown here):

  $ cat tkbhit.c
  #include <conio.h>
  #include <stdio.h>
  #include <windows.h>

  int main()
  {
    int key = 0;
    const char *spinner = "/-\\|";
    const char *flag = spinner;

    while( key != 27 )
    {
      if( *flag == '\0' )
        flag = spinner;

      printf( "%c\b", *flag++ );
      Sleep( 500 );

      if( _kbhit() )
        printf( "\nkbhit: %d\n", key = _getch() );
    }
    return 0;
  }

  $ gcc -o tkbhit.exe tkbhit.c

  $ ./tkbhit
  \
  kbhit: 122
  /
  kbhit: 27

  $

[**] Running in a virtualised (VirtualBox) WinXP-SP2 on my 
Ubuntu-8.04-LTS box it exhibits the above (expected) behaviour.  
Under Wine, on the same host, the kbhit() events go undetected, but 
in neither case does kbhit() block, as you describe; (IOW, in both 
cases, the "spinner" is continuously refreshed by the repeated 
printf() call).

-- 

Regards,
Keith.

On Tue, 2009-12-29 at 22:36 +0100, Erwin Waterlander wrote:
> Jonathan Andrews schreef:
> > Hi all,
> >
> > Im trying to write a console application that works on both linux and
> > windows and its driving me insane...
> >
> > Im using conio.h, but kbhit just blocks ? 
> >
> > Anyone any idea how I write a simple console application that actually
> > workes on console window in XP ?  The linux version of the same
> > application builds and runs but has an extra step of entering and
> > exiting raw mode on the tty.
> >
> > I need processing in the main loop so keyboard input can not block.
> >
> > Thanks,
> > Jon
> >   
> My experience is that conio is not working well on Windows. Even if you 
> use Borland C compiler.
I dont remember borlands kbhit being broken !

> DJGPP has excellent conio support. If a DOS program is sufficient you 
> could use DJGPP.
> Otherwise I would advise to use curses instead of conio, Ncurses on 
> Linux and PDcurses on Windows.

Thanks, useful info :-)

I have written the application using ANSI sequences, I didn't fancy
recoding it for curses. 

I followed your tip and download PDcurses, that had lots of PeekEvent
windows code looking for key events. After much searching and hacking I
found this:

http://cboard.cprogramming.com/cplusplus-programming/13937-kbhit-portability.html

MinGW conio kbhit is bust, cost me an entire day of pissing about -
maybe mingw should mention this in the notes......... 

Thanks for the help :-)
Jon

Jonathan Andrews schreef:
> Hi all,
>
> Im trying to write a console application that works on both linux and
> windows and its driving me insane...
>
> Im using conio.h, but kbhit just blocks ? 
>
> Anyone any idea how I write a simple console application that actually
> workes on console window in XP ?  The linux version of the same
> application builds and runs but has an extra step of entering and
> exiting raw mode on the tty.
>
> I need processing in the main loop so keyboard input can not block.
>
> Thanks,
> Jon
>   
My experience is that conio is not working well on Windows. Even if you 
use Borland C compiler.
DJGPP has excellent conio support. If a DOS program is sufficient you 
could use DJGPP.
Otherwise I would advise to use curses instead of conio, Ncurses on 
Linux and PDcurses on Windows.

regards,

-- 
Erwin Waterlander
Eindhoven
http://www.xs4all.nl/~waterlan/

Hi all,

Im trying to write a console application that works on both linux and
windows and its driving me insane...

Im using conio.h, but kbhit just blocks ? 

Anyone any idea how I write a simple console application that actually
workes on console window in XP ?  The linux version of the same
application builds and runs but has an extra step of entering and
exiting raw mode on the tty.

I need processing in the main loop so keyboard input can not block.

Thanks,
Jon

Vincent R. wrote:
> I wanted to know if yes or no we can put mingw in the same folder as msys.
> I always read it was not recommended but I would like to get a real
> answer.

Yes, you should be able to put MinGW in the same folder as MSYS. I
believe it is a valid use case. Please report any issues.

> Have you already had some issues ?

Just be careful not to install any packages intended for development of
MSYS itself, otherwise you will end up mixing MinGW- and MSYS-specific
tools, libraries and header files. The main ones to avoid are named like
*-msys-*-dev.tar.*, for instance
libiconv-1.13.1-1-msys-1.0.11-dev.tar.lzma

Cesar

On Monday 28 December 2009 19:52:18 Vincent R. wrote:
> I wanted to know if yes or no we can put mingw in the same folder
> as msys. I always read it was not recommended but I would like to
> get a real answer.

This is already well documented in past list postings; to summarise 
one last time:--

* Up to, and including MSYS-1.0.10, it was *imperative* that MSYS was 
kept in a *completely* separate path from MinGW, (an indeed from any 
other native Windows applications); native applications in the MSYS 
`/bin', (and its alias, `/usr/bin'), would not have access to any 
arguments passed on the command line, (so MinGW's gcc, etc., would 
*always* fail with a `no input files' diagnostic).

* From MSYS-1.0.11 onwards, it is permitted to merge MinGW into the 
MSYS tree.  However, since we maintain and distribute the two as 
entirely separate entities, we continue to recommend that you keep 
them segregated, simply to facilitate management of your local 
installation; if you don't care for this easier lifestyle, and your 
MSYS is at least MSYS-1.0.11, then by all means merge them.

> Have you already had some issues ?

Yes, but the serious issues arise only with MSYS-1.0.10 and earlier.  
Personally, I find it advantageous to segregate them, as I have a 
cautious approach to upgrading, when new versions are made available; 
with segregated installations, I can maintain parallel trees for 
different versions, and switch between them simply by adjusting the 
`/mingw' mount point definition in my active MSYS tree.

-- 

Regards,
Keith.