#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

[Earnie Boyd]

What does the following command show? I'm interested in the installed version. The 4.8.1-4 version had a patch applied that was supposed to aid in this issue.

mingw-get show gcc-bin

[Mifuyne]

I uninstalled MinGW earlier in the day and just reinstalled it to run the command you provided. It looks like g++ is behaving properly now.

In case you still want to see what the command output for me:

Package: mingw32-gcc                                  Subsystem: mingw32
Component: bin

Installed Version:  gcc-core-4.8.1-4-mingw32-bin.tar.lzma
Repository Version: gcc-core-4.8.1-4-mingw32-bin.tar.lzma

You may close this ticket. Thank you for your help :)

[Earnie Boyd]

The -4 is the release I expected to resolve this issue.

[TackyTexan]

I am having a similar problem.

Running "gcc.exe" no arguments pops up a dialog box:

"There is no disk in the drive. Please insert a disk into drive E:"

According to Process Monitor gcc.exe is attempting to access the following paths:

E:\p\giaw\mingw\share\locale\en_US\LC_MESSAGES\gcc.mo
E:\p\giaw\mingw\share\locale\en\LC_MESSAGES\gcc.mo
E:\p\giaw\mingw\lib\gcc\mingw32\specs

Below is the output of "mingw-get show gcc-bin" from MSYS shell:

Package: mingw32-gcc                                  Subsystem: mingw32
Component: bin

Installed Version:  gcc-core-4.8.1-4-mingw32-bin.tar.lzma
Repository Version: gcc-core-4.8.1-4-mingw32-bin.tar.lzma

Could this be a configuration issue on my system? What can I do to diagnose the problem?

Thanks

[Keith Marshall]

Re-opening, as a consequence of duplicate ticket [#2139].

Running identically the same version of MinGW-GCC as noted on that duplicate ticket, on 32-bit Win7 hosted via VirtualBox on my 64-bit Debian box:

strings /mingw/bin/gcc.exe | grep '[a-z]:/[a-z]'

shows me exactly the same list of drive E: and I: references, (and no others -- not even C: references), as observed by Nathan Crawford. However:

gcc -v nul.c -o nul.exe

shows only drive C: references, (for the include path searches).

Clearly, it remains a bug that these bogus drive E: and I: references are hard coded into the executable at all. I do wonder why it is, that they cause problems for some users, but not for others; FWIW, I do have a drive E:, (a mapped share, provided by my Debian host), but no drive I:. Perhaps it's the physical presence of a removable medium device, with no medium in place, that triggers the problem, but that's pure speculation.

Can those who observe the problem get past it, to post output from gcc -v? Can you map your removable medium devices to some other drives, (anything other than E: and I:)? If so, does that circumvent the issue?

[TackyTexan]

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

I have no drive mapped to E at the moment. The error message changes slightly:

"There is no disk in the drive. Please insert a disk into drive \Device\Harddisk1\DR9"

Is this the information you were looking for?

[Keith Marshall]

Yes, and no. It's sufficient to confirm that your installed MinGW-GCC was configured consistently with mine, for I see the same for bare

gcc -v

In my case, there is no error message. If I omit the -v, and provide no other arguments, nor options, I see:

$ gcc
gcc.exe: fatal error: no input files
compilation terminated.

which is as I would expect; there is certainly no complaint about there being no disk in any drive.

What I had hoped to see was the report of file system probes for include paths; it seems that, to get that we need to actually give GCC something to compile:

gcc -v -c nul.c

is sufficient. Also running:

gcc -### -c nul.c

may provide additional useful information, regarding the auxiliary programs which GCC runs.

[TackyTexan]

Here is the output of gcc -v -c dummy.c

$ 
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=pentiumpro'
 c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe -quiet -v -iprefix c:\mingw\b
in\../lib/gcc/mingw32/4.8.1/ dummy.c -quiet -dumpbase dummy.c -mtune=generic -ma
rch=pentiumpro -auxbase dummy -version -o C:\Users\Brett\AppData\Local\Temp\ccvO
kz2S.s
GNU C (GCC) version 4.8.1 (mingw32)
        compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/inclu
de"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../..
/../../include"
ignoring duplicate directory "/mingw/include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/inclu
de-fixed"
ignoring duplicate directory "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../..
/../../mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include
 c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include
 c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed
 c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include
End of search list.
GNU C (GCC) version 4.8.1 (mingw32)
        compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 767202a405449496e68a54c4eee91a28
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=pentiumpro'
 c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o dumm
y.o C:\Users\Brett\AppData\Local\Temp\ccvOkz2S.s
GNU assembler version 2.23.2 (mingw32) using BFD version (GNU Binutils) 2.23.2
COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/;c:/mingw/bin/../libexec
/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.8.1/;c:/mingw/bin/../lib/gcc/;c:/
mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;c:/mingw/bin/../lib/
gcc/mingw32/4.8.1/../../../
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=pentiumpro'

Here is the output of gcc -### -c dummy.c

Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-mtune=generic' '-march=pentiumpro'
 "c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe" -quiet -iprefix "c:\\mingw\
\bin\\../lib/gcc/mingw32/4.8.1/" dummy.c -quiet -dumpbase dummy.c "-mtune=generi
c" "-march=pentiumpro" -auxbase dummy -o "C:\\Users\\Brett\\AppData\\Local\\Temp
\\ccV39Wqk.s"
COLLECT_GCC_OPTIONS='-c' '-mtune=generic' '-march=pentiumpro'
 "c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe" -o dummy
.o "C:\\Users\\Brett\\AppData\\Local\\Temp\\ccV39Wqk.s"
COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/;c:/mingw/bin/../libexec
/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.8.1/;c:/mingw/bin/../lib/gcc/;c:/
mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;c:/mingw/bin/../lib/
gcc/mingw32/4.8.1/../../../
COLLECT_GCC_OPTIONS='-c' '-mtune=generic' '-march=pentiumpro'

I used the same hello world c program for both tests. As expected, both times I saw the same error boxes. Is this more helpful?

[Keith Marshall]

Thanks! That's certainly more informative, but I see no evidence of any probe of any drive, other than C:; nothing there seems to relate to the subject of this bug report.

[Scott R. Turner]

I want to echo that I have this same problem. An empty E: or I: drive causes the popup. Let me know if I can provide any other useful information.

[David Grayson]

This bug also affects me on Windows 8 64-bit.

I just installed MinGW today. My gcc.exe has hard-coded paths for the E: and I: drive. I have GCC 4.8.1 and the gcc-bin package has version gcc-core-4.8.1-4-mingw32-bin.tar.lzma. Here is the output from my shell (Git bash) showing this info:

$ strings /c/mingw/bin/gcc.exe | grep '[a-z]:/[a-z]'
e:/p
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
i:/p/giaw/mingw/share/locale

$ /c/MinGW/bin/gcc.exe -v
Using built-in specs.
COLLECT_GCC=c:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

$ mingw-get show gcc-bin

Package: mingw32-gcc                                  Subsystem: mingw32
Component: bin

Installed Version:  gcc-core-4.8.1-4-mingw32-bin.tar.lzma
Repository Version: gcc-core-4.8.1-4-mingw32-bin.tar.lzma

The GNU C Compiler
------------------

This package provides the MinGW implementation of  the  GNU  C  language
compiler;  this  includes  the  C  preprocessor, and the common back end
processors which are necessary to support all other  language  compilers
in the GNU Compiler Collection.

This is a required component of the MinGW Compiler Suite.

The card reader is built into my computer so it is not easy to just disconnect. I suppose I could try disabling it from the Device Manager though. Maybe I could just remap those drives off of the E: and I: letters.

[Eric D]

I had this same issue and my output was similar to the others in this thread. I resolved it by changing the drive letters so there was no drives with E: or I:. For reference they were a DVD drive and removable media drive.

[Cesar Strauss]

For those affected by this bug: please try the new versions I built for testing this issue. They are available at:

https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/experimental/

Files: gcc-try-1.tar.gz and gcc-try-2.tar.gz

Unpack them in an empty directory, go to the 'bin' directory and run 'gcc -v'. Do they trigger the disk error?

1) gcc-try-1.tar.gz

It was built from 4.8.2 without modification. I did use the "identity mount" setup, which was mentioned in: http://thread.gmane.org/gmane.comp.gnu.mingw.user/42991/focus=43002

In this build, the output from "strings" is reduced to:

 $ strings gcc.exe | grep '[a-z]:/[a-z]'
 i:/p/giaw/mingw/share/locale
 i:/p/giaw/mingw/share/locale

However, they could be false positives, so maybe they don't trigger the disk error.

2) gcc-try-2.tar.gz

It was built with --disable-nls. The output from "strings" is now empty:

$ strings gcc.exe | grep '[a-z]:/[a-z]'

The downside is no more translation of the compiler messages in other languages, at least until this gettext issue is solved.

Unfortunately, I am unable to trigger the bug, even though I do have removable drives on drives e: and i:.

I look forward to the tests results.

Regards,
Cesar

[Scott R. Turner]

On Sat, Dec 21, 2013 at 4:03 PM, Cesar Strauss cstrauss@users.sf.netwrote:

For those affected by this bug: please try the new versions I built for
testing this issue. They are available at:

https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/experimental/

Files: gcc-try-1.tar.gz and gcc-try-2.tar.gz

For me, Try #1 continues to exhibit the problem. Try #2 does not.

Let me know if you need any additional info.

-- Scott Turner

[Keith Marshall]

For me, Try #1 continues to exhibit the problem. Try #2 does not.

So, it would seem that this problem is inherited -- at least partially -- from the current gettext package.

Cesar, FWIW I had already started to follow up on some (fairly serious) packaging issues with gettext; perhaps we could use the thread I opened on MinGW-Dvlpr, (relating to this ticket), for further discussion of those issues, insofar as they may not be (directly) relevant here?

[Cesar Strauss]

Cesar, FWIW I had already started to follow up on some (fairly serious) packaging issues with gettext; perhaps we could use the thread I opened on MinGW-Dvlpr, (relating to this ticket), for further discussion of those issues, insofar as they may not be (directly) relevant here?

Sure.

For this bug, the faster solution is to recompile everything (gettext, binutils, gcc) using a working directory on drive c:. Then, recompile everything again after tracking down and solving the gettext bug.

Regards,
Cesar

[Keith Marshall]

For this bug, the faster solution is to recompile everything (gettext, binutils, gcc) using a working directory on drive c:.

I'm sure you are right. However, we do now have a significant number of degenerate packages polluting the mingw-get catalogues; I suspect we may not so readily overcome their legacy.

[Cesar Strauss]

For me, Try #1 continues to exhibit the problem. Try #2 does not.

Thanks for testing.

Could you also try running "ld -v"? Does it exhibit the problem?

I suspect binutils is also affected, but maybe it doesn't trigger the bug.

Regards,

Cesar

[Scott R. Turner]

On Sat, Dec 21, 2013 at 6:12 PM, Cesar Strauss cstrauss@users.sf.netwrote:

Could you also try running "ld -v"? Does it exhibit the problem?

I can't find "ld.exe" but "gcov.exe" has the same problem.

Scott

[Keith Marshall]

You must have ld.exe, otherwise your compiler will never be able to create executables.

Simply testing gcov.exe misses Cesar's objective entirely! Both gcc.exe and gcov.exe come from the same package, so it's unlikely that they would not exhibit the same problem. OTOH, ld.exe comes from the binutils package, (which you must also have installed, if your compiler is to work at all). Cesar is trying to ascertain if the build of binutils is similarly afflicted by this issue; since it is also linked with gettext, it may well be.

[Scott R. Turner]

Tell me where to find ld.exe and I'll be happy to test it.

[Keith Marshall]

Same place as gcc.exe, (nominally, that's C:/MinGW/bin, unless you relocated it when you ran mingw-get); if it isn't, then you have not installed all that you should have.

[Stefan Nonneman]

I have tried your Try 2 version and this works fine on my PC.
Do you provide an update in the MINGW distribution or should I extract all the files from your Try 2 ZIP file into the official package?

Thanks in advnace,

Stefan