Closed Bug 245903 Opened 21 years ago Closed 21 years ago

no system console output in MinGW builds

Categories

(SeaMonkey :: Build Config, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha2

People

(Reporter: dmosedale, Assigned: dmosedale)

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: [fixed-on-trunk])

Attachments

(2 files, 1 obsolete file)

In MinGW builds, there is no system console output. Among other things, this makes debugging SOAP stuff Very Hard.
Attached patch preliminary patch from silver (obsolete) — Splinter Review
Here's a preliminary patch that James gave me; iirc he said it's not yet ready for checkin. But it does work (thanks James!).
Assignee: general → dmose
Component: Browser-General → Build Config
I think Silver's on the right track here but running across that MOZ_WINCONSOLE switch makes me think that we're taking a slight different track with mingw compared to what msvc does. I'm guessing that with msvc builds, -console only works when MOZ_WINCONSOLE is set. Silver's changes would make -console work always. Using /subsystem:console by default may have other consequences. Dunno, IANAWP. Can someone point us to a resource which explains the exact differences between subsystem:windows & subsystem:console? For mingw builds, there's something about the -subsystem:windows link option (set by -mwindows) which causes the console related functions to fail. Neither _open_osfhandle nor WriteConsole work when -mwindows is used. Part of me is wondering if what we're attempting ever worked for msvc builds when linked with /subsystem:windows (ie, when MOZ_WINCONSOLE is not set). Can someone with msvc test this using the testcase I've attached?
Attachment #150286 - Attachment is obsolete: true
Based upon the irc discussion with dmose, mkaply & timeless, the majority of this problem seems from cygwin doing something funky with console redirection. If a mingw build is run using -console from a cmd.exe prompt, then the console window is opened and receives dump() output if you have that enabled. (I still don't think the _open_osfhandle is working in that case though. The testcase still fails.) From within a cygwin shell, you can do './mozilla | cat' and that will print the output as well. The MOZ_WINCONSOLE patch makes the mingw builds behave in the same fashion as the msvc builds.
Attachment #150839 - Flags: review?(dmose)
Comment on attachment 150839 [details] [diff] [review] use MOZ_WINCONSOLE for mingw r+sr=dmose. thanks chris!
Attachment #150839 - Flags: superreview+
Attachment #150839 - Flags: review?(dmose)
Attachment #150839 - Flags: review+
Attachment #150839 - Flags: approval1.7.1?
Whiteboard: [fixed-on-trunk]
Target Milestone: --- → mozilla1.8alpha2
Comment on attachment 150839 [details] [diff] [review] use MOZ_WINCONSOLE for mingw a=mkaply for 1.7.1
Attachment #150839 - Flags: approval1.7.1? → approval1.7.1+
Comment on attachment 150839 [details] [diff] [review] use MOZ_WINCONSOLE for mingw a=me for the aviary1.0 branch
Checked into the 1.7 branch. Awaiting the appearance of a fixed1.7.1 keyword.
Whiteboard: [fixed-on-trunk] → [fixed-on-trunk] [fixed-for-1.7.1]
Keywords: fixed1.7.1
Whiteboard: [fixed-on-trunk] [fixed-for-1.7.1] → [fixed-on-trunk]
Checked in on the Aviary 1.0 branch. Thanks for the patch, guys.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-on-trunk] → [fixed-on-trunk] fixed-aviary1.0
Product: Browser → Seamonkey
Keywords: fixed-aviary1.0
Whiteboard: [fixed-on-trunk] fixed-aviary1.0 → [fixed-on-trunk]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: