#2108 No Disk error when running g++ from cmd/tcc while a card reader with empty slots is connected.

[Mifuyne]

Running g++ with an empty (or partially filled) card reader will throw a No Disk error:

There is no disk in the drive. Please insert a disk into drive
\Device\Harddisk5\DR17.

Connecting the hub to other USB ports returns the same error (different DR). However, the compiler will still compile.

---

CONFIG INFO:

OS: Windows 7 Home Premium + SP1
GCC Version: 4.8.1
Binutils Version: 2.23.2
MinGW: 0.6.2-beta-20131004-1
Build Env: cmd.exe/tcc.exe

[Keith Marshall]

I'd like to help but I'm not exactly sure what to do.

I need assistance from someone who, starting out from a regular MinGW GCC-4.8.1 installation, (perhaps in a non-production sandbox), can:

1. Demonstrate that the regular installation exhibits the bug; if running gcc with no arguments is sufficient to do so, well and good.

2. Unpack my gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz, libgcc-4.8.2-mingw32-pre-20140218-1-dll-1.tar.xz, (and maybe some of the other preview DLLs), binutils-2.24-1-mingw32-bin.tar.xz, and libintl-0.18.3.1-2-mingw32-dll-8.tar.xz over the top of this installation, (after backing up, if you haven't created a separate sandbox for testing).

3. Run gcc --version, to confirm that you now are running 4.8.2.

4. If (3) isn't sufficient to demonstrate the bug, run whatever command was sufficient, to confirm whether or not the bug persists.

5. Install the requisite components, by unpacking my preview tarballs in place, for other GCC languages such as g++, gfortran, etc., and check that they also do not exhibit the bug.

6. Install the gcc-4.8.2-mingw32-pre-20140218-1-lang.tar.xz NLS language pack, and confirm that NLS support is working correctly; (see the example below).

7. Finally, check that you can compile any real world example of your own choice, using these preview tools.

However, the computer I tested it on doesn't have an E or I drive.

So, I guess condition (1) isn't satisfied; I've checked my preview builds on my own Win7 virtual machine, but on that I can't reproduce the bug we're trying to fix.

I ran "strings gcc.exe | grep '[a-z]:/a[-z]'" to look for hard-coded paths but did not see any, so that is good.

Nonetheless, they are there, (in the form /mingw/share/locale); they just aren't contaminated by the insanity of drive letters, because I built on a Linux host, with /mingw as prefix.

FWIW, here's the output on my VM, (where drive E: is a share exported by the Linux host, and the shell is MSYS bash), demonstrating operation of NLS support:

$ /e/mingw/bin/gcc --version
gcc.exe (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ LANGUAGE=/e/nls/locale/de /e/mingw/bin/gcc --version
gcc.exe (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

Note that you can install the NLS support pack in a directory other than /mingw/share/locale, if you specify a full absolute path with LANGUAGE=; (LC_MESSAGES= also works as an alternative, but I see strange, and undesirable side effects, if I specify it as either LANG= or LC_ALL=).

[David Grayson]

On Sun, Mar 9, 2014 at 10:02 AM, Keith Marshall
keithmarshall@users.sf.netwrote:

I need assistance from someone who, starting out from a regular MinGW
GCC-4.8.1 installation, (perhaps in a non-production sandbox), can:

Sorry for the 2-month delay, Keith, but I was able to do most your steps
just now.

First, I reproduced the bug with Windows prompting me to insert a card into
the card reader when I run the compiler. Just running "gcc" is sufficient.

Then I installed gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz using tar
-xvf (it wasn't actually zipped), running that command in C:/MinGW. As
soon as I did that, the bug was gone (and gcc --version reported 4.8.2). I
went ahead and
installed gcc-4.8.2-mingw32-pre-20140218-1-lang.tar.xz,
libgcc-4.8.2-mingw32-pre-20140218-1-dll-1.tar.xz,
binutils-2.24-1-mingw32-bin.tar.xz,
and libintl-0.18.3.1-2-mingw32-dll-8.tar.xz and the bug never came back.
My order was a little different than yours because I had trouble finding
some of the files (but Google helped).

I did not do step 5.

For step 6, I think NLS is working; here is my evidence:

$ LANGUAGE=/c/MinGW/share/locale/de gcc --version
gcc.exe (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE
ZWECKE.

For step 7, I compiled two small pieces of example code that talk to a
serial port using this new gcc, and everything seemed fine. I ran them,
but only to show that they printed the right error message about not
finding a serial port to talk to.

So anyway, your new builds work, and the bug is gone. Thanks!

--David Grayson

[Adam Koch]

I can confirm that my development environment displays the issue. Running "gcc" causes Windows 7 64-bit to pop up a No Disk dialog box when an unpopulated USB card reader is attached with a mapped E: drive. "gcc --version" reports 4.8.1.

In a sandbox MinGW environment unpacking gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz and libgcc-4.8.2-mingw32-pre-20140218-1-dll-1.tar.xz were sufficient to fix the problem. I was able to confirm that "gcc --version" reported 4.8.2.

I went ahead and unpacked binutils-2.24-1-mingw32-bin.tar.xz and libintl-0.18.3.1-2-mingw32-dll-8.tar.xz and observed that the problem is still fixed.

I did not test any of the other languages in Step 5.

I unpacked gcc-4.8.2-mingw32-pre-20140218-1-lang.tar.xz and after setting LANGUAGE i was able to prove that "gcc --version" provided a German output.

Let me know if there is anything else I can do to assist.

[obscureed]

Hi Keith,

Thanks for these instructions -- in particular, it was helpful to me that your step 2 details which files to download. (Some of the previous instructions linked only to directories with many files.) I can confirm that these steps allowed step 3 to pass.

I skipped on to step 7 and found that my v4.8.2 executables were a little slower than my previous versions. As an experiment, I tried v4.9.1 from Home / Toolchains targetting Win64 / Personal Builds / mingw-builds / 4.9.1 / threads-win32 / seh / x86_64-4.9.1-release-win32-seh-rt_v3-rev1.7z. (Home here means https://sourceforge.net/projects/mingw-w64/files/.) This seemed to be quicker than my previous version, so now I'm happy.

Thanks for your help.

[James Pack]

I was having the same issue on Window 8 64-bit and all I did was simply change the drive letter that was mapped to E:\ which happened to be an SD card reader to something else. Worked like a champ.

[Andy Clark]

First time poster, so apologies if I've missed something vital!

I've got an environment that reproduces the problem, and can confirm that the preview versions of gcc-4.8.2 fix the issue for gcc and binutils

Environment

I'm running Windows 8.1 on x64 configued to use UK English. E: for me is a fixed hard drive, I: is a card reader drive with no card in it.

gcc / binutils

I can provoke the error with stock packages by running gcc -v, ld -v or g++ -v. I get a message box that says:

No Disk: There is no disk in the drive. Please insert a disk into drive I

I followed Keith's instructions and unpacked all of the files listed in step 2. I then ran gcc -v and ld -v and did not get the message box error. I was able to confirm that the gcc version reported by was 4.8.2.

I then tried the new files for gfortran / libgfortran and g++ / libstdc++. These binaries also used to display the error, but the replacements do not.

From my point of view, gcc and binutils are now usable with these changes.

As an aside, during my investigations I noticed that gdb and gettext would still throw up the 'No Disk' errors when run with --version. For completeness, none of my replacements changed this, but I'm not sure I fully expected them to...

NLS support
I wasn't able to get the NLS support to work. Here are the results of my investigations:

Repro steps
1. Unpacked gcc-4.8.2-mingw32-pre-20140218-1-lang.tar.xz so that the contents went into /mingw
2. Confirmed that files had made it into the right place, e.g for German cpplib.mo and gcc.mo were found in /mingw/share/locale/de/LC_MESSAGES/
3. Ran the following from the MSYS bash shell: LANG=de gcc --version

Expected result
gcc version information in German

Actual result
gcc version information in English:

gcc.exe (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Other command lines tried
As setting languages and locales are fairly new to me, I tried the following command lines, each giving with the same English result:

$ LANGUAGE=/mingw/share/locale/de gcc --version
$ LANGUAGE=/mingw/share/locale/de /mingw/bin/gcc --version
$ LANG=de LANGUAGE=/mingw/share/locale/de /mingw/bin/gcc --version
$ LC_MESSAGES=/mingw/share/locale/de /mingw/bin/gcc --version
$ LC_MESSAGES=de /mingw/bin/gcc --version
$ LC_ALL=de gcc --version

Repros with stock packages
I repeated the same steps on my stock environment, and was not able to get the --version text to show in anything other than English there too.

MSYS packages respond OK to LANG variable
I tried to see if there were other programs that responded to LANG, to see if I was doing things wrong:

$ mingw-get install msys-wget-bin msys-wget-lang
$ wget
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

$ LANG=de wget
wget: URL fehlt
Syntax: wget [OPTION]... [URL]...

»wget --help« gibt weitere Informationen.

So wget (and other MSYS packages that I tried like dos2unix) showed German when LANG=de.

Their language files were installed to /usr/share/locale, so I tried copying the gcc language files to there too, but this didn't change anything, LANG=de gcc --version was still in English.

Replacing other parts of gettext
I tried including more components from https://sourceforge.net/projects/keithmarshall.u/files/mingw-gettext/:

1. I already had libintl-8.dll from libintl-0.18.3.1-2-mingw32-dll-8.tar.xz
2. I replaced libgettext(lib|po|src).dll with the ones from libgettextpo-0.18.3.1-2-mingw32-dll-0.tar.xz: no effect (LANG=de gcc -v still emits English text)
3. I replaced binaries and locale directories with those from gettext-0.18.3.1-2-mingw32-bin.tar.xz

After step 3, when I run LANG=de gettext -v or even just gettext -v, I get an error message box that says:

gettext.exe - Entry point not found.

The procedure entry point _set_invalid_parameter_handler could not be located in the dynamic link library C:\Development\MinGW\bin\gettext.exe

(My MinGW environment is rooted at C:\Development\MinGW)

At this point I think I'm a little out of my depth with gettext and language support, so I'll focus on the fact that the experimental gcc 4.8.2, binutils and ibintl-8.dll combinations fixed the initial problem for me. However, I can't get gcc to use a different locale, and gdb / gettext are still showing the original "No Disk" error.

I hope this helps - let me know if there's anything else I can do to help track this down.

[Keith Marshall]

I've got an environment that reproduces the problem, and can confirm that the preview versions of gcc-4.8.2 fix the issue for gcc and binutils

Thanks, Andy; this is good news!

I'm running Windows 8.1 on x64 configued to use UK English. E: for me is a fixed hard drive, I: is a card reader drive with no card in it.

I can provoke the error with stock packages by running gcc -v, ld -v or g++ -v. I get a message box that says:

No Disk: There is no disk in the drive. Please insert a disk into drive I

Excellent. This confirms that your environment is ideally suited to our test requirements ...

I followed Keith's instructions and unpacked all of the files listed in step 2. I then ran gcc -v and ld -v and did not get the message box error. I was able to confirm that the gcc version reported by was 4.8.2.

I then tried the new files for gfortran / libgfortran and g++ / libstdc++. These binaries also used to display the error, but the replacements do not.

From my point of view, gcc and binutils are now usable with these changes.

... while this suggests that my rebuilt packages do appear to avoid the "no disk" issue.

As an aside, during my investigations I noticed that gdb and gettext would still throw up the 'No Disk' errors when run with --version. For completeness, none of my replacements changed this, but I'm not sure I fully expected them to...

Well, latest gdb is another of Earnie's packages, which I didn't rebuild, and I guess that you're still running his defective gettext.exe build, at this point? (I suspect that everything Earnie has released, in the past couple of years, will be similarly afflicted by this bogus drive reference defect, and will thus need to be rebuilt).

I wasn't able to get the NLS support to work...

(My MinGW environment is rooted at C:\Development\MinGW)

Which wouldn't match the hard-coded NLS path of "/mingw/share/locale", which is present in my libintl-8.dll build; (this hard-coding will be interpreted as a native Windows path, not as an MSYS path, and is a bug inherent in, and propagated from the upstream GNU gettext project). Thus, your locale files will be in "C:/Development/MinGW/share/locale", so

LC_MESSAGES=de gcc --version

or other references to the default NLS path for German, certainly would not be expected to work; however, we might expect

LC_MESSAGES=/mingw/share/locale/de gcc --version

when run from an MSYS shell, and with MSYS path translation within the passed environment, to DTRT. Does it make any difference, if you specify it explicitly, as

LC_MESSAGES=/c/development/mingw/share/locale/de gcc --version

from the MSYS shell, or even as

set LC_MESSAGES=c:/development/mingw/share/locale/de
c:\development\mingw\bin\gcc --version

from a cmd.exe shell?

The procedure entry point _set_invalid_parameter_handler could not be located in the dynamic link library C:\Development\MinGW\bin\gettext.exe

This is a different issue, which may be related to another bug Earnie has flagged in the runtime libraries; it will certainly require further investigation.

[Andy Clark]

Well, latest gdb is another of Earnie's packages, which I didn't rebuild, and I guess that you're still running his defective gettext.exe build, at this point?

That's right.

(I suspect that everything Earnie has released, in the past couple of years, will be similarly afflicted by this bogus drive reference defect, and will thus need to be rebuilt).

I wondered if this would be the case. Fair enough!

Now, on to the NLS stuff

Does it make any difference, if you specify it explicitly, as LC_MESSAGES=/c/development/mingw/share/locale/de gcc --version from the MSYS shell

Success! This works, and I get gcc output in German! Running from cmd.exe works too. However,

we might expect LC_MESSAGES=/mingw/share/locale/de gcc --version when run from an MSYS shell, and with MSYS path translation within the passed environment, to DTRT.

This part didn't work for me. I have C:\Development\MinGW mounted as /mingw:

$ cat /etc/fstab
C:/Development/MinGW /mingw

$ mount
C:\Users\Andy\AppData\Local\Temp on /tmp type user (binmode,noumount)
C:\Development\MinGW\msys\1.0 on /usr type user (binmode,noumount)
C:\Development\MinGW\msys\1.0 on / type user (binmode,noumount)
C:\Development\MinGW on /mingw type user (binmode)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
f: on /f type user (binmode,noumount)
h: on /h type user (binmode,noumount)
i: on /i type user (binmode,noumount)
j: on /j type user (binmode,noumount)
k: on /k type user (binmode,noumount)

I'm still fairly new to MSYS / MinGW, so there's a good chance I've not configured things right.

[Garion]

I'm not the most tech savvy at this but I finally got around to trying out some of the files linked by Keith Marshall.

To begin with I'm using windows 8.1 64 bit and codeblocks 13.12

I was having the same problem with the "Please insert disk into E" error others were getting after I used the mingw-get gui application to install a fresh version of mingw.

I followed the link from Keith Marshall and downloaded
gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz
Then I unpacked it into the c:/MinGW directory (choose to overwrite all duplicate files)

After doing that I had no errors upon starting codeblocks. I went to create a new project but I received the no e disk drive error upon clicking the c++ main.cpp source file. It was a c++ project so I thought I'd try downloading the file
gcc-g++-4.8.2-mingw32-pre-20140218-1-bin.tar.xz
then I upacked it into the c:/MinGW directory as well (choose to overwrite duplicate files)

After that I was able to create a new console application and run a c++ hello world program. Not sure if this was helpful for anybody but I'll keep trying out stuff and see if I run into any errors.

Maybe now I can keep going on the winforgers tutorial ;p

[iVision]

Okay, I wrote a full report of this but apparantly it wasn't posted. It came down that after installing: gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz, gcc worked fine. Had the same problem with g++ but after overwritting with gcc-g++-4.8.2-mingw32-pre-2014021 that was also fixed.
Sorry for this small reply but I didn't feel like writing the whole reply again, I followed exactly what you said, it wasn't necessary to install the others you mentioned at point 2, although I did them.

Worth noticing: Running Windows 8.1 x64. If you still need a full report just say it and Ill write it later today ;)
Thank you so much for this fix works great :)

[Th0masR0ss]

I can confirm that this fix works on Windows 8.1 x64. I also had to update gcc-g++, but now it works! Thanks!

[Bob Cousins]

Having this problem on Windows 7 64 bit. I have just installed the latest version via package manager (first time install).

The error message I get is "There is no disk in the drive. Please insert a disk into drive \Device\Harddisk7\DR7".

I patched my install with file gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz and it now works ok. http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/experimental/gcc-4.8.2-preview/gcc-core-4.8.2-mingw32-pre-20140218-1-bin.tar.xz/download

Will there be an official update to fix this issue?

[John E Ross]

I got no disk in \DEVICE\HARDDISK\DR4 in my new installation which I think boils down to the program wanting something from drive I (Disk 4). So I changed Disk 4 to N and, with no disk I available, there is no problem!
--Windows 8.1 X64 and Windows 7 X64.

--John

[Austin Berrio]

I would just like to say that I'm still in the process of learning how programming works, namely that C is my first language and I pretty much barely know, let alone understand anything else.

Now on to business.

I would just like to state that changing the drive letter is NOT a fix; It just hides the error. The fact that this has been touted as the fix is quite annoying.

I'm not sure why Keith is so obsessed with the NLS/gettext within the program either? Or how this relates to the main issue at hand?

I would just like to note that Andy has provided some excellent feedback.

The executables gcc g++ etc etc seem to be the main cause of this issue. It may be a dll, but this all seems fishy to me.

However, I find it interesting that when I change the drive paths, this issue seems to be "resolved". A more interesting point is that gcc requires no arguments to produce this error what-so-ever. And gdb seems to NOT reproduce these issues as well.

Using ld (a process that occurs once the source has been parsed first) as a fix point doesn't make much sense to me either. Theres nothing to link and yet gcc still manages to produce this error.

I'm mainly re-addressing the obvious to point something out that hasn't seemed so obvious. What specifically causes this issue isn't so much as important as where the issue is originating from.

Why is gcc searching these pathways? What part of the mingw package is leading gcc to look into those paths in the first place?

Regardless, from my point of view, something is happening once any of these compilers is executed. No argument based input is required to incite these issues. A given pathway is requested even though the given pathway may or may not be obviously present. If the pathway is altered in anyway, the issue seems to "disappear" (even though it really hasn't). Why?

[Keith Marshall]

I would just like to state that changing the drive letter is NOT a fix;

I agree. It is a work-around, at best.

It just hides the error. The fact that this has been touted as the fix is quite annoying.

No need to be annoyed; no one has touted this as the fix. Those touting it as a fix are just regular users, who are satisfied with a crude work-around; they have no influence over what we, the project developers, will adopt as the eventual solution. My GCC-4.8.2 build is a move in the right direction, but I am unwilling to package it as the solution, because it will break Ada compiler support.

I'm not sure why Keith is so obsessed with the NLS/gettext within the program either?

I'm not obsessed by it, but it is a fundamental part of the problem. In fixing it, I would like to ensure that it not only no longer exhibits this issue, but that it also works correctly in its own right.

Or how this relates to the main issue at hand?

gettext is the provider of libintl-8.dll, upon which GCC is heavily dependent for national language support (NLS); as soon as it tries to put any message on to the screen, it will ask gettext for an NLS translation, and that will raise the very issue at hand, when gettext tries to probe some bogus drive, which is present but has no media in place. (In fact, it is the gettext probe which will have raised the issue for those running gcc without arguments, because that has nothing to do beyond displaying an appropriate message on screen).

[Francois Grieu]

For what it's worth: here's a report of that issue, under Win7x64 SP1 French with all updates, fresh install on 2015-05-27 of MinGW+MSYS using mingw-get-setup (0.602.22340 of 2014-06-11), which installed MinGW's gcc.exe 4.8.1 compiled 2013-10-05 (1819150 bytes, MD5 33157481a8491bc84f76662e0ea6d95f).

I open cmd.exe, CD to C:\MinGW\bin, do "gcc --version" and (before anything shows) get a popup window with "gcc.exe - no disk(..) insert a disk in reader \Device\Harddisk3\DR3" (translated from French to English). The popup can be dismissed by clicking continue, and eventually I'll get the version.

This Harddisk3 is a SDCard reader, with no SD card inserted, that came with the case of the PC. It is a "Generic STORAGE DEVICE USB Device" as reported by properties/hardware, default-installed using Microsoft's USBSTOR.SYS 6.1.7601.17577.

The problem specifically occurs when that SDCard reader is assigned the drive letter I: (the popup will show just once) or E: (the popup will show 7 times). It does not occur for several other random letters that I tried, and does not occur for empty physical DVD-RW assigned to E: or I: (nor BD-ROM emulation using VirtualCloneDrive).

I guess not coincidentally, gcc.exe contains the following hard-coded path referencing drive letters E: and I:
e:/p/giaw/mingw/lib/gcc/
e:/p/giaw/mingw/libexec/gcc/
e:/p/giaw/mingw/bin/
e:/p/giaw/mingw
e:/p/giaw/mingw/share/locale
i:/p/giaw/mingw/share/locale (twice)

My guess is that gcc.exe references one of these path (which is a bug), and something in windows decides that the smart thing is to ask for the media, given some attribute it has.

[Mark Ziegast]

FWIW, while I agree with Keith that something in gettext is causing the dialogs to pop up, that all those absolute path strings get put in gcc means to me there's a bug in the linker; in that it isn't using a means of referencing package-install time location(s) that indirectly point to the containing dirs of the lib modules or nls/locale data. This indirection is partly part of shortcut/pif files in Windows. A file holding entries for each installed package could have a defaults section for common roots, so specific entries are only needed if an administrator specifies a non-default location. Further refinement for global installs and user specific testing installs is plausible too.

The .m4,.in,.ac files would still need fixing upstream, but that would give them an additional generic option to assuming builddir = newhostinstalldir on canadian-cross compiles. Autoconf would need an --enable-indirectroots option too, that would add the appropriate linker settings to LDFLAGS for exes and dlls. Some of the plugins have similar issues, given the number of references to top_build a full text search of the gcc sources produces.

[raynebc]

I just ran into this issue on a recent MinGW 4.8.1-4 installation (regarding no disk in my optical drive), which is weird because it worked for a while and then I suddenly couldn't use it. On a whim I close all open command windows and terminated explorer.exe and started it again. I was then able to use GCC without the "no disk in the drive" error. With a workaround this simple I'm not terribly worried, but I'm curious if enough is known by the MinGW team to work on a permanent fix yet. If more testing is needed, please let me know what I should try if/when this problem comes up again on my system.

[Keith Marshall]

Yes, we already have a fix for this -- it's in the GCC-4.8.2 offering on our download pages. The only reason that this isn't the current release already is that I have not been able to successfully build it with Ada support; if you don't need Ada, then go ahead and install GCC-4.8.2, as explained elsewhere on this ticket.

Apart from seeking a solution for the Ada issue, (which is unrelated to the specific subject of this ticket), I'm considering this as closed.

[Oddity]

If this is resolved, why do I still encounter this problem when I update to the latest packages?

What is the correct way for me to fix it?

[Francois Grieu]

A workaround follows from the observation this occurs only when some devices (like, unused Flash disk adaptors) are assigned drive letter E or I
in disk manager (windows key then diskmgmt.msc) modify assignments of letters to drives so that these letters E and I are unasigned, or assigned to peripherals that cause no issue (CD-ROMs and physical hard disks work fine for me).

[Oddity]

That worked, thanks!

[Keith Marshall]

But, as has been mentioned elsewhere on the ticket, IIRC, it is just a workaround, rather than a solution; (specifically, it mitigates a symptom of the problem, rather than addressing its cause).

If you are still seeing this issue, with any GCC version other than 4.8.1, then you must still have residual dependencies on some DLL, or other subsidiary module, (among the gettext/libintl/libiconv i18n modules, perhaps), which exhibits the same problem, and you have failed to replace.