From: Bob R. <bob...@co...> - 2008-01-08 16:20:08
|
Hi, I currently am having a problem with the gcc-4.2-sjlj compiler and GDB. Basically, gdb doesn't behave correctly on the 'next' command. It jumps to an odd position and I eventually have to quit gdb. The up/down doesn't work either, as GDB doesn't seem to understand the frames correctly. My question is, is this normal or just a side effect of me using the 4.2 release candidate? Any suggestions on how to improve this? I'm using the latest release candidate gdb from the website. GNU gdb 6.7.50.20071127 Also, why is the freenode #mingw channel invite only now? It didn't start that way. Bob Rossi |
From: Vincent T. <vt...@un...> - 2008-01-08 17:44:13
|
On Tue, 8 Jan 2008, Bob Rossi wrote: > Also, why is the freenode #mingw channel invite only now? It didn't > start that way. it's quite strange for an open source project. Not really open. Vincent Torri |
From: Fredric J. <joh...@ho...> - 2008-01-08 18:00:43
|
Vincent Torri wrote: > On Tue, 8 Jan 2008, Bob Rossi wrote: >=20 > > Also, why is the freenode #mingw channel invite only now? It didn't > > start that way. >=20 > it's quite strange for an open source project. Not really open. >=20 > Vincent Torri Hello I might be able to explain that The channel moved to ##mingw since it isnt official and a forwarding #mingw->##mingw was setup before. It seems to have been removed and apparently resulting in the channel being invite-only. If you want to know why it's invite-only, I guess you should ask the staff on freenode. Fredric Johansson _________________________________________________________________ St=E5r karri=E4ren still? L=E5t n=E5gon annan hitta dr=F6mjobbet =E5t dig! http://msn.jobbguiden.se/jobseeker/resumes/postresumenew/postresumestart.as= px?sc_cmp2=3DJS_INT_SEMSN_NLPCV= |
From: Soren A. <so...@bl...> - 2008-01-08 19:38:47
|
On Tue, 8 Jan 2008 19:00:35 +0100 Fredric Johansson <joh...@ho...> wrote: > Vincent Torri wrote: > > On Tue, 8 Jan 2008, Bob Rossi wrote: > > > > > Also, why is the freenode #mingw channel invite only now? It > > > didn't start that way. > > > > it's quite strange for an open source project. Not really open. > > > > Vincent Torri > > Hello > I might be able to explain that > The channel moved to ##mingw since it isnt official and a > forwarding #mingw->##mingw was setup before. It seems > to have been removed and apparently resulting in the channel > being invite-only. If you want to know why it's invite-only, I > guess you should ask the staff on freenode. > > Fredric Johansson For completeness when future readers are browsing, at least, please let me add the following about #mingw@freenode: Due to Freenode (http://freenode.net) policy, only someone who has official status as a representative of a recognized F/L-OSS project may authorize the creation of a single-octothorpe ("#", "hash") -named channel on Freenode. http://freenode.net/group_registration.shtml. And since of the current volunteer participants who are in ##mingw (the "other" kind of Freenode channel, completely unofficial), none have such status with the MinGW Project, the #mingw channel will remain locked, like an office space or warehouse that has been abandoned. Earnie Boyd has, I am told, been sent email about this some weeks ago from other channel participants than myself. If he's not received it or chosen to ignore it for whatever (I'm sure perfectly good) reason, then the situation with people looking to use IRC to discuss* mingw will remain the same. Someone who fits the above criteria as an authorized representative of mingw has to contact Freenode staff. When they do, they can specify that "mingw" (the official F/L-OSS Project) wishes for an autoforwarding of joins #mingw -> ##mingw to be reinstated permanently, or they can choose some other status for the channel. As a result of the situation (locked room) remaining the same, it's reasonable to predict that questions of this sort will continue to be received on the mingw-users ML from time to time. Those of us who "support" ##mingw@freenode cannot do anything about it ourselves. For the record, I am an alternate (co-) contact person for the new-ish (at the writing) UNofficial channel ##mingw. I am not on Freenode network staff. *a personal opinion on using IRC to support technical projects: It's my personal viewpoint that IRC is mostly unproductive and wasteful, even detrimental, as a medium on which to cooperate in co-development of F/L-OSS projects, or on which to support users of such projects. "Wasteful" of developer's scarce free time, which will be spent on attempting to reply to redundant FAQs put forward by barely-coherent individuals in a spoken language that only remotely resembles English; such queries will much of the time be shown, after multiple attempts have been made to get clarification on the asker's intended meaning, to have been asked after minimal or no "homework" has been done by that person, to familiarize themselves with the fundamentals and known procedures. "Unproductive" as well because of the emphemeral (temporary) nature of IRC; unless channel logs are pubilcy kept in a known location, any discussions that take place are gone later, never to be usable again by persons needing to get similar information (unlike a Mailing List). "Detrimental" due to several interpenetrating factors: the absence of emotional maturity, professionalism and objectivity which is demonstrably problematic on most text media online is probably worse on IRC than on any "persistent" medium (speculatively, because many users regard it as more of a playground and venting outlet than as a serious venue for respectful intellectual exchanges?). Due also to the rampant set of antisocial negativities which often go unchallenged (and thus grow more frequent: "Silence betokens consent") on IRC channels: sexism/homophobia/racism (the perpetrators almost never admit to harboring such intent or attitudes). This is detrimental to individual projects but even more so to Free Software as a social movement and struggle to assert humanistic and benevolent values against the default social values of short-sighted greed and erroneous self-interest. It is so because it hinders the expansion of diversity within the community of F/L-OSS users and developers (anyone noticed how White and Male we are lately?). The kinds of thoughtless or malicious statements I've seen on the Freenode IRC network tech channels are the same kinds of things for which several public figures have been losing their livelihoods and reputations in the past 24 months (at least in the US). No one who is paying any attention here in my country can claim that the kind of irresponsible, juvenile or malicious speech of which I am speaking is harmless or has no potential impact. So that this Off-Topic matter can be cleanly closed, I'll answer the inevitable question in advance: "If IRC is so bad and so unsuitable, why are YOU involved in it, somian?" Because of a couple of factors. One is the small number of productive and interesting exchanges that do take place amidst the general waste. From time to time I get to know very worthy people on IRC in a way that would take much longer on other media. Another is the neurological dependency (please avoid annoying me with whining complaints about "psycho-babble", thanks) that I have on the unique immediacy of IRC. Me and those like me find that it gets our neurotransmitters humming happily to be engaging in the occasional exchange on IRC. This isn't a recommendation. I don't wish the reader to get hooked on crank, either. Another is the belief that there may be a small benefit to the public perception of the health of the mingw project if the ##mingw channel does produce at least timely (< 12 hours wait) responses to requests for help or advice. People do not share my observations about IRC. They have what I view as deluded or ignorant expectations about IRC, so they come to a channel like #mingw/##mingw expecting that if they get helped, it reflects on the vitality, the viability or the good health of the project with which the channel is associated. Many times my response to a request for help is to refer the asker to the official MinGW venues for support (Wiki, MLs, archives of MLs). Thanks for your attention, everyone. Soren Andersen (somian) -- All unaccompanied children will be given espresso and a free kitten. ---------------------------------------------------------------------- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4 |
From: Brandon S. <br...@oq...> - 2008-01-08 19:42:51
|
On Jan 8, 2008, at 8:12 AM, Bob Rossi wrote: > I currently am having a problem with the gcc-4.2-sjlj compiler and > GDB. > Basically, gdb doesn't behave correctly on the 'next' command. It > jumps > to an odd position and I eventually have to quit gdb. > > The up/down doesn't work either, as GDB doesn't seem to understand > the frames > correctly. My question is, is this normal or just a side effect of me > using the 4.2 release candidate? > hi Bob, Is gcc-4.2-dw2 an option for you? I've been using that with great success on the last several versions of GDB. I've witnessed the frames error myself on gdb 6.x as well. ps. to whomever knows, is sjlj being deprecated in favor of dw2 in mainline gcc? Brandon Sneed |
From: Earnie B. <ea...@us...> - 2008-01-08 21:34:26
|
Quoting Soren Andersen <so...@bl...>: > Earnie Boyd has, I am told, been sent email about this some weeks ago > from other channel participants than myself. If he's not received it or > chosen to ignore it for whatever (I'm sure perfectly good) reason, then > the situation with people looking to use IRC to discuss* mingw will > remain the same. Someone who fits the above criteria as an authorized > representative of mingw has to contact Freenode staff. When they do, > they can specify that "mingw" (the official F/L-OSS Project) wishes for > an autoforwarding of joins #mingw -> ##mingw to be reinstated > permanently, or they can choose some other status for the channel. > I responded and even CCed Keith. IRC is not a sanctioned means of communication for MinGW. > > *a personal opinion on using IRC to support technical projects: > > It's my personal viewpoint that IRC is mostly unproductive and > wasteful, even detrimental, as a medium on which to cooperate in > co-development of F/L-OSS projects, or on which to support users of > such projects. > I feel the same and besides do not have a means to use IRC within the time frame that I am usually responding to the list. (--8<--) Nice summary. Thanks Soren. Earnie |
From: Brian E. <be...@me...> - 2008-01-09 08:47:24
|
Bob Rossi <bob...@co...> writes: > Any suggestions on how to improve this? I'm using the latest release > candidate gdb from the website. GNU gdb 6.7.50.20071127 Do you use any optimization options when compiling? -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: Peter B. <pb...@hg...> - 2008-01-09 10:38:34
|
> I currently am having a problem with the gcc-4.2-sjlj compiler and GDB. > Basically, gdb doesn't behave correctly on the 'next' command. It jumps > to an odd position and I eventually have to quit gdb. > > The up/down doesn't work either, as GDB doesn't seem to understand the frames > correctly. My question is, is this normal or just a side effect of me > using the 4.2 release candidate? Mmm, I think I had this problem too. I added the -gstabs compiler option (see gcc-manual) and it was gone. Peter |
From: Bob R. <bob...@co...> - 2008-04-18 14:39:39
|
On Thu, Jan 10, 2008 at 05:17:41PM +1300, Danny Smith wrote: > > > > > > I currently am having a problem with the gcc-4.2-sjlj > > compiler and GDB. > > > Basically, gdb doesn't behave correctly on the 'next' > > command. It jumps > > > to an odd position and I eventually have to quit gdb. > > > > > > The up/down doesn't work either, as GDB doesn't seem to > > understand the frames > > > correctly. My question is, is this normal or just a side > > effect of me > > > using the 4.2 release candidate? > > > > Mmm, I think I had this problem too. I added the -gstabs > > compiler option > > (see gcc-manual) and it was gone. > > > > > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155 Sorry for the long delay. I recompiled with -gstabs and everything works! I hope this bug is fixed someday, as the future is moving forward with dwarf2. Here is the other debugger error that I get, (gdb) .....warning: HEAP[TestSuite.exe]: warning: Invalid Address specified to RtlFreeHeap( 003D0000, 05E31070 ) Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) up #3 0x7c96cd80 in ntdll!RtlpNtMakeTemporaryKey () from /cygdrive/c/WINDOWS/syste m32/ntdll.dll (gdb) up #4 0x05e31068 in once.33033 () (gdb) up #5 0x003d0000 in ?? () (gdb) up #6 0x05e31070 in once.33033 () (gdb) #7 0x0022e898 in ?? () (gdb) #8 0x7c96df66 in ntdll!RtlpNtMakeTemporaryKey () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) up #9 0x003d0000 in ?? () (gdb) #10 0x05e31068 in once.33033 () (gdb) #11 0x7c96e11c in ntdll!RtlpNtMakeTemporaryKey () from /cygdrive/c/WINDOWS/syste m32/ntdll.dll (gdb) #12 0x003d0000 in ?? () (gdb) #13 0x05e31070 in once.33033 () (gdb) #14 0x40000060 in ?? () (gdb) #15 0x00000000 in ?? () (gdb) Initial frame selected; you cannot go up. (gdb) Initial frame selected; you cannot go up. Now, at this point, if I continue I get the error message again. I have to do this about 200 times before I get somewhere in my code that I want to be. I've found an alternative is to type, signal SIGTRAP nopass noprint nostop however, gdb warns, SIGTRAP is used by the debugger. Are you sure you want to change it? (y or n) y SIGTRAP is used by the debugger. So, is this OK? Thanks, Bob Rossi |
From: Bob R. <bob...@co...> - 2008-04-30 13:17:18
|
Hi, Was this the correct email list for the below information? Should I report this to gcc mailing list? Thanks, Bob Rossi > Sorry for the long delay. I recompiled with -gstabs and everything > works! I hope this bug is fixed someday, as the future is moving forward > with dwarf2. > > Here is the other debugger error that I get, > > (gdb) > .....warning: HEAP[TestSuite.exe]: > warning: Invalid Address specified to RtlFreeHeap( 003D0000, 05E31070 ) > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x7c901231 in ntdll!DbgUiConnectToDbg () from > /cygdrive/c/WINDOWS/system32/ntdll.dll > (gdb) up > #3 0x7c96cd80 in ntdll!RtlpNtMakeTemporaryKey () from /cygdrive/c/WINDOWS/syste > m32/ntdll.dll > (gdb) up > #4 0x05e31068 in once.33033 () > (gdb) up > #5 0x003d0000 in ?? () > (gdb) up > #6 0x05e31070 in once.33033 () > (gdb) > #7 0x0022e898 in ?? () > (gdb) > #8 0x7c96df66 in ntdll!RtlpNtMakeTemporaryKey () from > /cygdrive/c/WINDOWS/system32/ntdll.dll > (gdb) up > #9 0x003d0000 in ?? () > (gdb) > #10 0x05e31068 in once.33033 () > (gdb) > #11 0x7c96e11c in ntdll!RtlpNtMakeTemporaryKey () from /cygdrive/c/WINDOWS/syste > m32/ntdll.dll > (gdb) > #12 0x003d0000 in ?? () > (gdb) > #13 0x05e31070 in once.33033 () > (gdb) > #14 0x40000060 in ?? () > (gdb) > #15 0x00000000 in ?? () > (gdb) > Initial frame selected; you cannot go up. > (gdb) > Initial frame selected; you cannot go up. > > Now, at this point, if I continue I get the error message again. I have > to do this about 200 times before I get somewhere in my code that I want > to be. I've found an alternative is to type, > signal SIGTRAP nopass noprint nostop > however, gdb warns, > SIGTRAP is used by the debugger. > Are you sure you want to change it? (y or n) y > SIGTRAP is used by the debugger. > > So, is this OK? |
From: Bob R. <bob...@co...> - 2008-04-30 13:24:40
|
On Fri, Apr 18, 2008 at 10:38:58AM -0400, Bob Rossi wrote: > Sorry for the long delay. I recompiled with -gstabs and everything > works! I hope this bug is fixed someday, as the future is moving forward > with dwarf2. > > Here is the other debugger error that I get, > > (gdb) > .....warning: HEAP[TestSuite.exe]: > warning: Invalid Address specified to RtlFreeHeap( 003D0000, 05E31070 ) To follow up on my own thread, I know that each DLL in windows can have it's own heap. I also know that you can't new an object in one, and delete it in another, unless you use the /MD switch with cl. So, how does this effect mingw's gcc? Is there a similar gcc flag or do the rules not apply? Thanks, Bob Rossi |
From: Earnie B. <ea...@us...> - 2008-04-30 19:20:11
|
Quoting Bob Rossi <bob...@co...>: > On Fri, Apr 18, 2008 at 10:38:58AM -0400, Bob Rossi wrote: >> Sorry for the long delay. I recompiled with -gstabs and everything >> works! I hope this bug is fixed someday, as the future is moving forward >> with dwarf2. >> >> Here is the other debugger error that I get, >> >> (gdb) >> .....warning: HEAP[TestSuite.exe]: >> warning: Invalid Address specified to RtlFreeHeap( 003D0000, 05E31070 ) > > To follow up on my own thread, I know that each DLL in windows can have > it's own heap. I also know that you can't new an object in one, and > delete it in another, unless you use the /MD switch with cl. > More like does have rather than can have. > So, how does this effect mingw's gcc? Is there a similar gcc flag or do > the rules not apply? > Have you considered the shared memory API? Earnie |
From: Brian D. <br...@de...> - 2008-04-30 16:53:46
|
Bob Rossi wrote: > To follow up on my own thread, I know that each DLL in windows can have > it's own heap. I also know that you can't new an object in one, and > delete it in another, unless you use the /MD switch with cl. > > So, how does this effect mingw's gcc? Is there a similar gcc flag or do > the rules not apply? cl /MD literally means "use MSVCRT.DLL" instead of statically linking the runtime into the executable. The problem you are referring to is specific to MSVC because there you can choose between a vast combination of runtimes (static or dynamic; single or multithreaded; debug or non-debug) and so you run into problems if you try to use a library that was built with e.g. the static singlethreaded runtime linked to a main program that was built with the dynamic MT runtime. But MinGW supports only[1] one option: dynamic MSVCRT.DLL, so this is pretty much irrelevant. It's not like we can distribute Microsoft's static libraries. Regarding heaps, gcc has no knowledge of how the underlying platform implements memory management; all it needs to know is that there is a malloc() in the libc on which it can base 'operator new', that's it. And since malloc() is implemented by MSVCRT.DLL, this means that all calls go through one instance. [1] Well I guess technically there is also support for CRTDLL.DLL but *nobody* uses that as it is way ancient and I would guess extremely broken. Brian |
From: Bob R. <bob...@co...> - 2008-04-30 19:27:21
|
On Wed, Apr 30, 2008 at 09:53:42AM -0700, Brian Dessent wrote: > Bob Rossi wrote: > > > To follow up on my own thread, I know that each DLL in windows can have > > it's own heap. I also know that you can't new an object in one, and > > delete it in another, unless you use the /MD switch with cl. > > > > So, how does this effect mingw's gcc? Is there a similar gcc flag or do > > the rules not apply? > > cl /MD literally means "use MSVCRT.DLL" instead of statically linking > the runtime into the executable. OK, I know you are correct about this, however, I do know from experience, that the actual translation unit is different when you provide the /MD flag. It's not just a linker flag. I'm assumming that cl does something terrible to ensure that when /MD is given, some part of the translation unit is included or not included. Does this happen for free with gcc? or is it perhaps a non issue? (ie. if the /MD effects the windows.h include, does gcc need to mimmic this)? > The problem you are referring to is > specific to MSVC because there you can choose between a vast combination > of runtimes (static or dynamic; single or multithreaded; debug or > non-debug) and so you run into problems if you try to use a library that > was built with e.g. the static singlethreaded runtime linked to a main > program that was built with the dynamic MT runtime. But MinGW supports > only[1] one option: dynamic MSVCRT.DLL, so this is pretty much > irrelevant. It's not like we can distribute Microsoft's static > libraries. > > Regarding heaps, gcc has no knowledge of how the underlying platform > implements memory management; all it needs to know is that there is a > malloc() in the libc on which it can base 'operator new', that's it. > And since malloc() is implemented by MSVCRT.DLL, this means that all > calls go through one instance. OK, if what you say is true, how do I get this, .....warning: HEAP[TestSuite.exe]: warning: Invalid Address specified to RtlFreeHeap( 003D0000, 06071070 ) Program received signal SIGTRAP, Trace/breakpoint trap. Everything I read online says it happens when data is free'd from one heap and malloc'd in another. When I run my program from outside GDB, I don't get these warnings, that strikes me as rather odd. A backtrace in gdb at this point is essentially meaningless. GDB actually says, frame inner to this frame (corrupt stack?) When I do a search for this on the web, I find that just about everyone in the mingw community has this issue and nobody can resolve it. I'm going to continue researching. Any help would be appreciated. Thanks, Bob Rossi |
From: Bob R. <bob...@co...> - 2008-04-30 19:29:12
|
On Wed, Apr 30, 2008 at 03:20:02PM -0400, Earnie Boyd wrote: > > Quoting Bob Rossi <bob...@co...>: > > > On Fri, Apr 18, 2008 at 10:38:58AM -0400, Bob Rossi wrote: > >> Sorry for the long delay. I recompiled with -gstabs and everything > >> works! I hope this bug is fixed someday, as the future is moving forward > >> with dwarf2. > >> > >> Here is the other debugger error that I get, > >> > >> (gdb) > >> .....warning: HEAP[TestSuite.exe]: > >> warning: Invalid Address specified to RtlFreeHeap( 003D0000, 05E31070 ) > > > > To follow up on my own thread, I know that each DLL in windows can have > > it's own heap. I also know that you can't new an object in one, and > > delete it in another, unless you use the /MD switch with cl. > > > > More like does have rather than can have. > > > So, how does this effect mingw's gcc? Is there a similar gcc flag or do > > the rules not apply? > > > > Have you considered the shared memory API? No, I'm not actually sure what you are talking about. Could you elaborate a little more. Hmm, if you are suggesting that _I_ want to new/delete memory in different dll's, than you are misunderstanding. I link everything statically. I just want this error to not show up in GDB. However, GDB won't tell me the call chain that gets it into this state using bt. Thanks, Bob Rossi |
From: Brian D. <br...@de...> - 2008-05-01 00:12:15
|
Bob Rossi wrote: > OK, I know you are correct about this, however, I do know from > experience, that the actual translation unit is different when you > provide the /MD flag. It's not just a linker flag. I'm assumming that cl > does something terrible to ensure that when /MD is given, some part of > the translation unit is included or not included. > > Does this happen for free with gcc? or is it perhaps a non issue? > (ie. if the /MD effects the windows.h include, does gcc need to mimmic > this)? MSVCRT is the multithread version of the runtime, so _MT (or whatever the define is called) gets defined, just as _ST (or whatever the define or lack of a define is called) gets defined when you use the singlethreaded version. Whatever the headers do with that define is up to them (e.g. stdio inlines), but the same thing happens when you use -mthreads with gcc. > OK, if what you say is true, how do I get this, > .....warning: HEAP[TestSuite.exe]: > warning: Invalid Address specified to RtlFreeHeap( 003D0000, 06071070 ) > Program received signal SIGTRAP, Trace/breakpoint trap. > Everything I read online says it happens when data is free'd from one > heap and malloc'd in another. > > When I run my program from outside GDB, I don't get these warnings, that > strikes me as rather odd. A backtrace in gdb at this point is > essentially meaningless. GDB actually says, > frame inner to this frame (corrupt stack?) > > When I do a search for this on the web, I find that just about everyone > in the mingw community has this issue and nobody can resolve it. > > I'm going to continue researching. Any help would be appreciated. You can't get a backtrace because gdb has no debug information and Windows system DLLs have FPO enabled so there's no way to unwind the stack. This is a debugging trap. You don't see it outside of a debugger as there is no debugger to act on it. It doesn't sound that strange to me that some system DLLs generate traps under some circumstances if the process is being debugged. If anything, the fact that you see the trap when there is a debugger is just alerting you to something that's always present but simply ignored under normal circumstances. Just like normally the output of "OutputDebugString()" goes nowhere, but if you run dbgview or debug the program you'll see it. The classic example are those "IsValid{Read,Write}Ptr()" functions in kernel32.dll. They generate access faults if the argument passed is in fact not valid, and those faults are totally normal as the function has installed a SEH handler to catch them. But the debugger still gets the first chance at handling the fault regardless of what handlers are installed. And therefore most Win32 debuggers have to have an option to ignore access faults that occur within kernel32.dll for this very reason. Another random example that I've experienced is that I've seen rpcrt4.dll (part of the operating system) generate SIGTRAP when calling gethostbyname() if I have the 'DNS Client' service disabled. Again, there's nothing erronious going on here. Name resolution works just fine as I had a local bind9 server running. But for whatever reason the OS generated a debugging trap under those circumstances, and of course a debugging trap with no debugger present cannot be detected so it's not like this ever affected the program. If anything this just indicates that gdb should be taught/configured to ignore traps that it did not insert itself. Brian |
From: Keith M. <kei...@us...> - 2008-01-09 19:34:49
|
On Tue, 2008-01-08 at 16:34 -0500, Earnie Boyd wrote: > Quoting Soren Andersen <so...@bl...>: > > > Earnie Boyd has, I am told, been sent email about this some weeks ago > > from other channel participants than myself. If he's not received it or > > chosen to ignore it for whatever (I'm sure perfectly good) reason, then > > the situation with people looking to use IRC to discuss* mingw will > > remain the same. Someone who fits the above criteria as an authorized > > representative of mingw has to contact Freenode staff. When they do, > > they can specify that "mingw" (the official F/L-OSS Project) wishes for > > an autoforwarding of joins #mingw -> ##mingw to be reinstated > > permanently, or they can choose some other status for the channel. > > > > I responded and even CCed Keith. I don't recall that; perhaps I wasn't paying proper attention. > IRC is not a sanctioned means of communication for MinGW. Nor should it be, IMO; we can offer a much better standard of support through the medium of the mailing lists. > > *a personal opinion on using IRC to support technical projects: > > > > It's my personal viewpoint that IRC is mostly unproductive and > > wasteful, even detrimental, as a medium on which to cooperate in > > co-development of F/L-OSS projects, or on which to support users of > > such projects. > > I feel the same ... As do I. > ... and besides [I] do not have a means to use IRC within the time > frame that I am usually responding to the list. Same for me. > (--8<--) Nice summary. Thanks Soren. Seconded. Regards, Keith. |
From: Soren A. <so...@bl...> - 2008-01-09 23:10:51
|
[Executive summary of another lengthy message from me: Doing nothing except confirming that IRC is not a sanctioned means of obtaining support for mingw *here on the Mailing List*, Keith and Earnie, is not going to affect the existence of the #mingw channel on Freenode. If you guys want to clean up a situation which perhaps should not have ever happened in the first place, someone is going to need to do something more.] On Wed, 09 Jan 2008 19:35:43 +0000 Keith Marshall <kei...@us...> wrote: > > IRC is not a sanctioned means of communication for MinGW. > > Nor should it be, IMO; we can offer a much better standard of support > through the medium of the mailing lists. To wind up this discussion (on which we've seen helpful unanimity ;-), I just need to make the following point directed specifically to Earnie and Keith. The channel #mingw at Freenode was at some point more than 2-1/2 years ago, created at Freenode with the creator-person representing himself as having official sanction to do so by mingw. If that was not the case, then either a fraud was perpetrated or the standards of vetting requests for channel 'blessing' were lax at Freenode at that time. Either way, a channel with the appearance of having official mingw status *does exist already* (as the previous messages indicate). Now, just recently, a channel that does not have such an appearance is also in existence (that's ##mingw). Doing nothing except confirming that IRC is not a sanctioned means of obtaining support for mingw *here on the Mailing List*, Keith and Earnie, is not going to affect the existence of the #mingw channel on Freenode. If you guys want to clean up a situation which perhaps should not have ever happened in the first place, someone is going to need to do something more. If you don't care that #mingw is an abandoned locked office (and I am not indicating that I am sure you should care; it is a matter of subjective opinion as far as I am concerned), then don't do anything further. If, however, you perceive that with minimal effort you can cut future noise (in the form of repeated inquires and comments like the ones that sparked this discussion, see the message that came before the one from Fredric), then contact Freenode and explain the non-sanctioned status of #mingw to them. AFAIK, you cannot get #mingw completely removed (because someone can, using a simple IRC /join command, always come along and simply re-create it -- but without any channel permanence and protection). The system management policy at Freenode (AFAIUI) is to have #mingw locked forever and have it maybe give users a message or bounce them into some other place where they see displayed "This channel cannot be used" or something of the sort. That way, because it already exists, it cannot be resurrected my miscreants ;-) As a *side issue* I will point out the obvious: mingw cannot control the existence or operation of any ":about:" -type channel on Freenode; the people on ##mingw can always have their channel whether it's blessed or not. So far I think that the core of people there are doing an ok job of making it clear that the channel is completely unofficial and of pointing people towards the official mingw support venues. We over there are not antagonistic or hostile towards Keith or Earnie or anyone else and don't wish to subvert the centralization of mingw support at the official venues (do we, guys?). Most of us came to a #mingw channel that was abandoned by its original owner (who fraudulently had it blessed then abandoned it?) and saw something that might be worth saving. We may have been wrong to do that. The trouble with a situation like the abandonment of #mingw (in past when it was still accessible) is that people still come and squat there. And many times they give out incorrect information and advice to each other. This in turn potentially increases the workload for people doing support on the official venues because they have to work out what 'strange ideas people have heard "somewhere else"' and correct them. Isn't that so? Here's a paste of the /topic displayed presently for ##mingw: --------%<--------------------------------------------------- Unofficial MinGW Channel | http://mingw.org and http://mingw.org/cms | Be patient and wait if you ask a question. | Latest Files: http://sf.net/projects/mingw/ | Read before asking FAQs about the ld linker: http://tinyurl.com/27wkzb | Don't forget that MS Windows is documented at Microsoft: Google site:msdn2.microsoft.com <keywords> --------%<--------------------------------------------------- I think that makes it's status clear enough? Finito ;-) Soren "somian" Andersen -- All unaccompanied children will be given espresso and a free kitten. ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com/tag/1 |
From: Earnie B. <ea...@us...> - 2008-01-10 12:29:45
|
Quoting Soren Andersen <so...@bl...>: > [Executive summary of another lengthy message from me: > Doing nothing except confirming that IRC is not a sanctioned means of > obtaining support for mingw *here on the Mailing List*, Keith and > Earnie, is not going to affect the existence of the #mingw channel on > Freenode. If you guys want to clean up a situation which perhaps should > not have ever happened in the first place, someone is going to need to > do something more.] > I really don't care. > On Wed, 09 Jan 2008 19:35:43 +0000 > Keith Marshall <kei...@us...> wrote: > >> > IRC is not a sanctioned means of communication for MinGW. >> >> Nor should it be, IMO; we can offer a much better standard of support >> through the medium of the mailing lists. > > To wind up this discussion (on which we've seen helpful unanimity ;-), > I just need to make the following point directed specifically to Earnie > and Keith. > > The channel #mingw at Freenode was at some point more than 2-1/2 years > ago, created at Freenode with the creator-person representing himself as > having official sanction to do so by mingw. If that was not the case, > then either a fraud was perpetrated or the standards of vetting > requests for channel 'blessing' were lax at Freenode at that time. > I had probably said it was OK because I really don't care. > Either way, a channel with the appearance of having official mingw > status *does exist already* (as the previous messages indicate). Now, > just recently, a channel that does not have such an appearance is also > in existence (that's ##mingw). > > Doing nothing except confirming that IRC is not a sanctioned means of > obtaining support for mingw *here on the Mailing List*, Keith and > Earnie, is not going to affect the existence of the #mingw channel on > Freenode. If you guys want to clean up a situation which perhaps should > not have ever happened in the first place, someone is going to need to > do something more. > If you *Soren Andersen* wish to take on the #mingw channel support, consider this email an official sanction to do so. > If you don't care that #mingw is an abandoned locked office (and I > am not indicating that I am sure you should care; it is a matter of > subjective opinion as far as I am concerned), then don't do anything > further. If, however, you perceive that with minimal effort you can cut > future noise (in the form of repeated inquires and comments like the > ones that sparked this discussion, see the message that came before the > one from Fredric), then contact Freenode and explain the non-sanctioned > status of #mingw to them. > --8<-- > > Here's a paste of the /topic displayed presently for ##mingw: > > --------%<--------------------------------------------------- > Unofficial MinGW Channel | http://mingw.org and http://mingw.org/cms > | Be patient and wait if you ask a question. | Latest Files: > http://sf.net/projects/mingw/ | Read before asking FAQs about the ld > linker: http://tinyurl.com/27wkzb | Don't forget that MS Windows is > documented at Microsoft: Google site:msdn2.microsoft.com <keywords> > --------%<--------------------------------------------------- > The http://mingw.org/cms is only a development version and should not be stated as official. Also the site list for Google should be microsoft.com and not with msdn2.microsoft.com; you miss a lot of information that way. Earnie |