printf: doens't print on WinXP installation

[Alex Bilyk]

Hi,

Just installed GNUstep on Win XP. Doing the simplest of things with a main
function that has printf("hello, world"); in it. Everything compiles and
runs, except there is no output to the console. I can step through code in
dgb and it goes over this line fine. A bit of a puzzle. Tried to use
NSLog(@"..."); version - same result. App is built and run successfully,
but with no printout to the console. Any ideas? BTW, stepping in gdb over
the NSLog version has some issues that the printf version doesn't have, but
that's a separate topic. I'm really after the printout at the moment, as you
might imagine:)

Thanks,
Alex
--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p25528385.html
Sent from the GNUstep - Help mailing list archive at Nabble.com.

[Fred Kiefer]

Alex Bilyk schrieb:

> Just installed GNUstep on Win XP. Doing the simplest of things with a main
> function that has printf("hello, world"); in it. Everything compiles and
> runs, except there is no output to the console. I can step through code in
> dgb and it goes over this line fine. A bit of a puzzle. Tried to use
> NSLog(@"..."); version - same result. App is built and run successfully,
> but with no printout to the console. Any ideas? BTW, stepping in gdb over
> the NSLog version has some issues that the printf version doesn't have, but
> that's a separate topic. I'm really after the printout at the moment, as you
> might imagine:)

Hi Alex,

I cannot help you with printf which is a library function, but for NSLog
I am able to tell you that most likely you will find its output in the
event viewer of windows. You may change this by setting the user default
GSLogSyslog. Running with gdb should also result in the output going to
the terminal.

Which terminal are you using?

Fred

[Alex]

Here's the output I get 

Alex Bilyk@ASUS ~/projects/helloworld

$ make

This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help.

Making all for app HelloWorld...

 Compiling file main.m ...

 Linking app HelloWorld ...

Creating library file: ./HelloWorld.app/./HelloWorld.exe.a

Alex Bilyk@ASUS ~/projects/helloworld

$ openapp ./HelloWorld

Alex Bilyk@ASUS ~/projects/helloworld

$ defaults read NSGlobalDomain

NSGlobalDomain GSLogSyslog NO

I ran 

$ defaults write NSGlobalDomain GSLogSyslog NO 

prior to the run. Can there be something wrong with the console itself? Does output use UTF8, that might be causing this issue? In any case even  though the value above is set to NO, NSLog outputs still go to the event viewer.

Thanks for helping out,

Alex

---

From: Fred Kiefer <fredk...@gmx.de>
To: Alex Bilyk <to_d...@yahoo.com>
Cc: Help-g...@gnu.org
Sent: Sunday, September 20, 2009 9:22:57 AM
Subject: Re: printf: doens't print on WinXP installation

[Fred Kiefer]

Did you try to run your application under gdb? Does this result in the
NSLog output being shown in the terminal?
The format used should depend on your settings, but as long as you only
output ASCII characters, UTF8 should do no harm.

Alex schrieb:

[jacksk58]

I am running into the same problem as Alex Bilyk. -- "printf: doens't print
on WinXP installation", when compiled by GNUmakefile. It works, when
compliled, without the makefile. I like compliling by GNUmakefiles. Can
someone tell me why, printf("hello, world") doesn't work when complied by
GNUmakefiles. I'm only curious about the problem with Printf.

Thanks

Alex Bilyk wrote:
>
> Hi,

>
> Just installed GNUstep on Win XP. Doing the simplest of things with a main
> function that has printf("hello, world"); in it. Everything compiles and
> runs, except there is no output to the console. I can step through code in
> dgb and it goes over this line fine. A bit of a puzzle. Tried to use
> NSLog(@"..."); version - same result. App is built and run successfully,
> but with no printout to the console. Any ideas? BTW, stepping in gdb over
> the NSLog version has some issues that the printf version doesn't have,
> but that's a separate topic. I'm really after the printout at the moment,
> as you might imagine:)
>

> Thanks,
> Alex
>

--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26002055.html

[jacksk58]

I am running into the same problem as Alex Bilyk. -- "printf: doens't print
on WinXP installation", when compiled by GNUmakefile. It works, when

compiled, without the makefile. I like compiling by GNUmakefiles. Can
someone tell me why, printf("hello, world") doesn't work when compiled by

GNUmakefiles. I'm only curious about the problem with Printf.

Thanks

Alex Bilyk wrote:
>
> Hi,
>
> Just installed GNUstep on Win XP. Doing the simplest of things with a main
> function that has printf("hello, world"); in it. Everything compiles and
> runs, except there is no output to the console. I can step through code in
> dgb and it goes over this line fine. A bit of a puzzle. Tried to use
> NSLog(@"..."); version - same result. App is built and run successfully,
> but with no printout to the console. Any ideas? BTW, stepping in gdb over
> the NSLog version has some issues that the printf version doesn't have,
> but that's a separate topic. I'm really after the printout at the moment,
> as you might imagine:)
>
> Thanks,
> Alex
>

--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26002070.html

[Richard Frith-Macdonald]

On 22 Oct 2009, at 00:52, jacksk58 wrote:

>
> I am running into the same problem as Alex Bilyk. -- "printf:
> doens't print
> on WinXP installation", when compiled by GNUmakefile. It works, when

> compliled, without the makefile. I like compliling by GNUmakefiles.

> Can
> someone tell me why, printf("hello, world") doesn't work when

> complied by

> GNUmakefiles. I'm only curious about the problem with Printf.
>
> Thanks
>
>
> Alex Bilyk wrote:
>>
>> Hi,
>>
>> Just installed GNUstep on Win XP. Doing the simplest of things with
>> a main
>> function that has printf("hello, world"); in it. Everything
>> compiles and
>> runs, except there is no output to the console. I can step through
>> code in
>> dgb and it goes over this line fine. A bit of a puzzle. Tried to use
>> NSLog(@"..."); version - same result. App is built and run
>> successfully,
>> but with no printout to the console. Any ideas? BTW, stepping in
>> gdb over
>> the NSLog version has some issues that the printf version doesn't
>> have,
>> but that's a separate topic. I'm really after the printout at the
>> moment,
>> as you might imagine:)
>>
>> Thanks,

I think it might help to have the code and the makefile to see if
anyone can reproduce this ... printf works fine for me.

[jacksk58]

I'm runnuning this on an XP installation. I'm supplying - hello.m,
GNUmakefile and the text from the GNUStep Shell

Thanks

hello.m
===========
#import <stdio.h>

int main( int argc, const char *argv[] ) {
printf( "hello world\n" );

return 0;
}

GNUmakefile
==============
include $(GNUSTEP_MAKEFILES)/common.make

APP_NAME = HelloWorld
HelloWorld_OBJC_FILES = hello.m

include $(GNUSTEP_MAKEFILES)/application.make

GNUStep Shell 'Screen Shot'
========================
Setting up GNUstep Environment...

kj@CR ~

$ make
This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help.
Making all for app HelloWorld...

Creating HelloWorld.app/....
Compiling file hello.m ...

Linking app HelloWorld ...
Creating library file: ./HelloWorld.app/./HelloWorld.exe.a

Creating HelloWorld.app/Resources...
Creating stamp file...
Creating HelloWorld.app/Resources/Info-gnustep.plist...
Creating HelloWorld.app/Resources/HelloWorld.desktop...

kj@CR ~
$ openapp ./HelloWorld.app

kj@CR ~
$

> _______________________________________________
> Help-gnustep mailing list
> Help-g...@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnustep
>
>

--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26019875.html

[Eduardo Osorio Armenta]

try this:

#include <stdio.h>
instead of :          #import <stdio.h> 

regards

[Richard Frith-Macdonald]

On 23 Oct 2009, at 15:25, Eduardo Osorio Armenta wrote:

try this:

#include <stdio.h>
instead of :          #import <stdio.h> 

I'm afraid that won't make any difference.

[Adam Fedor]

Oh, yes - you are trying to compile this as an Application. In that
case, GNUstep adds some special flags to keep Windows from trying to
output stuff to a command window. If you really want to see the
output of printf, you'll have to compile it as a tool:

TOOL_NAME=HelloWorld
include $(GNUSTEP_MAKEFILES)/tool.make

or you could use NSLog (but that goes to the Windows system log unless
you are using gdb).

[Richard Frith-Macdonald]

On 23 Oct 2009, at 03:23, jacksk58 wrote:

>
> I'm runnuning this on an XP installation. I'm supplying - hello.m,
> GNUmakefile and the text from the GNUStep Shell
>
> Thanks
>
> hello.m
> ===========
> #import <stdio.h>
>
> int main( int argc, const char *argv[] ) {
> printf( "hello world\n" );
>
> return 0;
> }
>
> GNUmakefile
> ==============
> include $(GNUSTEP_MAKEFILES)/common.make
>
> APP_NAME = HelloWorld
> HelloWorld_OBJC_FILES = hello.m
>
> include $(GNUSTEP_MAKEFILES)/application.make

I just tried that on my XP system, and it printed 'hello world' as
expected.
I'm using a setup made by installing the latest windows packaged from
the gnustep website, and then updating to the latest code from svn
trunk, but it seems very unlikely that any version difference would
have changed the behavior of standard file operations.

The only thing I can suggest is that there's some problem with your
installation.

You could try running the program directly ...

./HelloWorld.app/HelloWorld.exe

or running it under gdb

gdb ./HelloWorld.app/HelloWorld.exe

[Richard Frith-Macdonald]

On 23 Oct 2009, at 15:44, Adam Fedor wrote:

> Oh, yes - you are trying to compile this as an Application. In that
> case, GNUstep adds some special flags to keep Windows from trying to
> output stuff to a command window.

But on my system, I was able to build exactly that program and with
that makefile (ie as an app) and launch the resulting app using
'openapp', and it still printed 'hello world'

Perhaps some setting I made in the past has changed windows' behavior
to always print to stdout though.

[Adam Fedor]

On Oct 23, 2009, at 8:50 AM, Richard Frith-Macdonald wrote:

>
> On 23 Oct 2009, at 15:44, Adam Fedor wrote:
>
>> Oh, yes - you are trying to compile this as an Application. In
>> that case, GNUstep adds some special flags to keep Windows from
>> trying to output stuff to a command window.
>
> But on my system, I was able to build exactly that program and with
> that makefile (ie as an app) and launch the resulting app using
> 'openapp', and it still printed 'hello world'
>
> Perhaps some setting I made in the past has changed windows'
> behavior to always print to stdout though.

There's a link flag: -mwindows

which is supposed to suppress console output. When I take that out, I
can see the printf statements, otherwise I don't. I'm using the
standard GNUstep Windows Installer package. Perhaps you have a custom
MingW install that's different?

I know -mwindows is supposed to be deprecated as well. I'll have to
update gnustep-make...

[Eduardo Osorio Armenta]

ok, i just extract this from discuss-gnustep.gnu.org  list:

http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/msg00149.html

David Chisnal wrote:
On 14 Oct 2009, at 00:30, Jean-Loïc Mauduy wrote:

#import <stdio.h>

This is wrong.  A few Objective-C tutorials make this mistake, and tell you to just use #import instead of #include in Objective-C programs, but this is terrible advice.  #include is a trivial preprocessor directive that just inserts the contents of the specified file at this point.  #import is a bit more clever, and ensures that the file is only ever inserted once.

Objective-C headers are, generally, designed to be used with #import.  A lot of C (and C++) headers, however, are not.  They will protect themselves from multiple inclusion with macros and may be designed to work differently if included more than once in a compilation unit.  If you get into the habit of using #import with C headers, then you are going to end up with something breaking eventually, and you are going to be very confused about why.  Only use #import with Objective-C headers; stick with #include for C headers.  This also provides a clue to people reading your code about what kind of header you are including.

David

Best Regards

[Richard Frith-Macdonald]

On 23 Oct 2009, at 17:54, Eduardo Osorio Armenta wrote:

On Fri, Oct 23, 2009 at 9:41 AM, Richard Frith-Macdonald <ric...@tiptree.demon.co.uk> wrote:

On 23 Oct 2009, at 15:25, Eduardo Osorio Armenta wrote:

try this:

#include <stdio.h>
instead of :          #import <stdio.h> 

I'm afraid that won't make any difference.

ok, i just extract this from discuss-gnustep.gnu.org  list:

http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/msg00149.html

Sure, that's good advice generally, but in this case (where stdio.h is the only file being included/imported) there is no practical difference between the two.

[jacksk58]

Everybody's suggestion worked -- using GNUmakefile with tool.make, removing
-mwindows from application.make and using GNUmakefile with application.make,
using #import <stdio>. I got everything to work now and I understand the
difference between application.make (use for GUI Apps) and tool.make (use
for Console / Command Line Apps) now.

Thanks for your help

jacksk58 wrote:
>
> I'm runnuning this on an XP installation. I'm supplying - hello.m,
> GNUmakefile and the text from the GNUStep Shell
>
> Thanks
>
> hello.m
> ===========
> #import <stdio.h>
>
> int main( int argc, const char *argv[] ) {
> printf( "hello world\n" );
>
> return 0;
> }
>
> GNUmakefile
> ==============
> include $(GNUSTEP_MAKEFILES)/common.make
>
> APP_NAME = HelloWorld
> HelloWorld_OBJC_FILES = hello.m
>
> include $(GNUSTEP_MAKEFILES)/application.make
>
>

--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26030114.html

[jacksk58]

I changed the hello.m file to include your suggestion, still no / go.

I'm running this on an XP installation. I'm supplying - hello.m,

GNUmakefile and the text from the GNUStep Shell

Thanks

hello.m
===========
#include <stdio.h>

return 0;
}

GNUmakefile
==============
include $(GNUSTEP_MAKEFILES)/common.make

include $(GNUSTEP_MAKEFILES)/application.make

kj@CR ~
$

Thanks

eduardo osorio armenta-2 wrote:
>
> try this:
>
> #include <stdio.h>
> instead of : #import <stdio.h>
>

> regards

>> http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26019875.html

>> Sent from the GNUstep - Help mailing list archive at Nabble.com.
>>
>>
>>

>> _______________________________________________
>> Help-gnustep mailing list
>> Help-g...@gnu.org
>> http://lists.gnu.org/mailman/listinfo/help-gnustep
>>
>
> _______________________________________________
> Help-gnustep mailing list
> Help-g...@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnustep
>
>

--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26027544.html

[Alex Bilyk]

I'm glad the group has gotten to the bottom of this. Though, I've since got
meself a Mac and doing iPhone development.

Thanks

Richard Frith-Macdonald-2 wrote:
>
>
> On 23 Oct 2009, at 17:54, Eduardo Osorio Armenta wrote:
>
>> On Fri, Oct 23, 2009 at 9:41 AM, Richard Frith-Macdonald
>> <ric...@tiptree.demon.co.uk
>> > wrote:
>>

>> On 23 Oct 2009, at 15:25, Eduardo Osorio Armenta wrote:
>>
>>> try this:
>>>
>>> #include <stdio.h>
>>> instead of : #import <stdio.h>
>>

>> I'm afraid that won't make any difference.
>>
>> ok, i just extract this from discuss-gnustep.gnu.org list:
>>
>> http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/
>> msg00149.html
>
>
> Sure, that's good advice generally, but in this case (where stdio.h is
> the only file being included/imported) there is no practical
> difference between the two.
>
>

> _______________________________________________
> Help-gnustep mailing list
> Help-g...@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnustep
>
>

--
View this message in context: http://www.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p26031589.html

[Ashley Holland]

> >> a main function that has printf("hello, world"); in it. Everything
> >> compiles and runs, except there is no output to the console. I can

This might explain the problem..

http://www.mail-archive.com/help-g...@gnu.org/msg01822.html

[engr0123]

No need to change anything. Compile as you have done originally.
The output can be seen here (I am using Windows XP):

Go to: Control panel | Administrative Tools | Computer Management
Under System Tools, click Event Viewer, and then Application.

On right side, double click the entry generated by your App. You will see
your printf of NSLog output at the end of the text that is shown in a
dialog.

Alex Bilyk wrote:
>
> Hi,
>
> Just installed GNUstep on Win XP. Doing the simplest of things with a main

> function that has printf("hello, world"); in it. Everything compiles and

> runs, except there is no output to the console. I can step through code in
> dgb and it goes over this line fine. A bit of a puzzle. Tried to use
> NSLog(@"..."); version - same result. App is built and run successfully,
> but with no printout to the console. Any ideas? BTW, stepping in gdb over
> the NSLog version has some issues that the printf version doesn't have,
> but that's a separate topic. I'm really after the printout at the moment,
> as you might imagine:)
>
> Thanks,

> Alex
>

--
View this message in context: http://old.nabble.com/printf%3A-doens%27t-print-on-WinXP-installation-tp25528385p32304193.html

[Eric Wasylishen]

Hey,
To elaborate a bit.. I struggled with this problem as well, and it turns out to be a quirk in windows.

A windows exe has a "subsystem" property - if it uses the console subsystem, printf output will go to the console as you'd expect. The problem is, if you use the console subsystem for a gui app, a console window will open every time you start the app.

Likewise, there's a "gui" subsystem which won't cause a console window to open, but printf output goes nowhere, even if you start the gui app from a console window.

GNUstep-make uses the console subsystem if you build a GNUstep Tool, and the gui subsystem if you build a GNUstep Application. So, for gui applications, your best bet is to use NSLog and read the output from the event viewer, -or- run the application in gdb, and NSLog output will appear in the gdb console.

Hope this helps
--Eric

> _______________________________________________
> Help-gnustep mailing list
> Help-g...@gnu.org

> https://lists.gnu.org/mailman/listinfo/help-gnustep