[Developers] MinGW "nasty problem"

[John Sibert]

Hi Jon,
Thanks for the useful analysis. It certainly clarifies the situation 
with respect to MinGW. I''l give your proposed solution a try when Karen 
authorizes me to use her computer.

I do not believe, however, that the problem is strictly caused by 
MingGW. A bit of quick work searching on the string "there is no disk in 
the drive.please insert a disk into drive" reveals that "Microsoft has 
confirmed that this is a problem in the Microsoft products that are 
listed at the beginning of this article." 
(http://support.microsoft.com/kb/330137). Other hits propose editing the 
registry to suppress (all?) error messages, eg
http://answers.microsoft.com/en-us/windows/forum/windows_7-system/there-is-no-disk-in-the-drive-please-insert-a-disk/c8e0c1bd-18f6-4799-a9fb-67bedff9bc9f
and
http://www.youtube.com/watch?v=7khU0ZY9gBU

It may be that MinGW is not written in a way to avoid this Windows 
"feature".

That being said, your proposed software alternatives seem reasonable, at 
least to a person who avoids microsoft products as much as possible.

John

John Sibert
Emeritus Researcher, SOEST
University of Hawaii at Manoa
Honolulu HI (GMT-10)
808-294-3842

Visit the ADMB project http://admb-project.org/

On 12/08/2013 10:40 PM, Jon Schnute wrote:
> Hi John - Your experience with the MinGW "nasty problem" matches mine
> exactly. I've done a lot of research on this, and I've written the attached
> report "MinGW problem with drives that don't exist". I think you'll find
> that it offers a credible explanation. It contains many Internet links that
> connect you with other sources.
>
> Along with other developers (cited in the report), I've concluded that the
> original MinGW project has fallen off the rails and can no longer be
> considered reliable. We need to move to the independent new project
> MinGW-w64. In the long run, we need to do this anyway to get 64-bit support.
>
> I hope my little report convinces everyone involved. I'm copying Wade Cooper
> on this because he reported success with ADMB in the message he sent on
> November 18.
>
> In my next message, I'll send my recommendations for the explicit software I
> think we should use.
>
> Best wishes,
>
> Jon
>
> -----Original Message-----
> From: John Sibert [mailto:sibert at hawaii.edu]
> Sent: December-06-13 9:54 AM
> To: Jon Schnute; 'Johnoel Ancheta'; developers at admb-project.org
> Cc: 'Haigh, Rowan'
> Subject: Re: [Developers] Big changes in Revision 1438
>
> Hi Jon,
> Thank you for your patience in testing this stuff. It can be onerous in
> windows.
>
> Regarding the "nasty problem with MinGW" that you mentioned, I may have
> encountered something similar.
>
> I was trying to install admb on my wife's new windows 7 machine and the
> procedure ran smoothly until it started to build the libraries. As soon as
> it started to compile the first source file, the system popped up an error
> window titled "g++" containing the error message "There is no disk in the
> drive. Please insert a disk in drive \Device\Harddisk2\DR2."
> Further experimentation revealed the error window any time g++ starts.
> So it appears not to be anything to do with admb; it is an windows/mingw
> issue.
>
> Searching for a solution was pretty fruitless. I lot of know-nothing
> responses to similar questions and BS remarks from microsoft flacks about
> how important solving the problem is to microsoft. But the responses pointed
> to usb drive issues.
>
> So I'm wonder if this is the "nasty problem" you mentioned, and if so, how
> it was solved.
>
> Cheers,
> John
>
>
> John Sibert
> Emeritus Researcher, SOEST
> University of Hawaii at Manoa
> Honolulu HI (GMT-10)
> 808-294-3842
>
> Visit the ADMB project http://admb-project.org/
>
> On 12/05/2013 11:17 PM, Jon Schnute wrote:
>> I've tested revisions 1444 and 1447 on Windows 7 using Msys and MinGW,
>> obtained independently from the Internet. The build process worked in
>> both cases with no problems. Also, the executable files and scripts in
>> ..\build\dist successfully converted .tpl files to .exe files.
>>
>> In the process, I discovered a nasty problem with MinGW that stems
>> from a bug in Windows. It will occur if you connect and disconnect a
>> USB drive before using MinGW.
>>
>> I'm planning to write installation instructions that document exactly
>> what I've done, along with a warning about the potential MinGW problem
>> and its resolution. I'll circulate this document when I have a draft.
>>
>> I should add that Rowan Haigh, using the official QuickStart procedure
>> on revision 1444, encountered the problem with "banner.cpp" that I've
>> described in earlier email. When we have the opportunity, we'll check
>> into this further and send a bug report if we can reproduce the problem.
>>
>> Again, thanks to everyone for your good work cleaning up the code.
>>
>> Jon
>>
>> *From:*developers-bounces at admb-project.org
>> [mailto:developers-bounces at admb-project.org] *On Behalf Of *Johnoel
>> Ancheta
>> *Sent:* December-05-13 1:32 AM
>> *To:* developers at admb-project.org
>> *Subject:* [Developers] Big changes in Revision 1438
>>
>> Hi all,
>>
>> The ADMB build files have again been reworked and improved. After
>> getting
>>
>> feedback,
>>
>> * the build files have been simplified a bit more
>>
>> - Dave Fournier
>>
>> * works with Rtools (but not with Rtools->make)
>>
>> - Jon Schnute
>>
>> * should build in Windows if Msys or Rtools are in the system PATH
>>
>> A lot of time and effort was spent by everyone to test and develop
>>
>> the build scripts.
>>
>> Please test the installation by following documentation in
>>
>> http://www.admb-project.org/buildbot/documentation/
>>
>> Changes and QuickStart pages are in the the directory.
>>
>> Thanks to everyone who participated in the testing.
>>
>> Johnoel
>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at admb-project.org
>> http://lists.admb-project.org/mailman/listinfo/developers
>