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

OTHER
closed
Earnie Boyd
None
Bug
fixed
IINR_-_Include_In_Next_Release
False
2 days ago
2013-10-14
Mifuyne
No

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

Related

Issues: #2108
Issues: #2139
Issues: #2146
Issues: #2153
Issues: #2183

Discussion

1 2 3 > >> (Page 1 of 3)
  • Earnie Boyd
    Earnie Boyd
    2013-10-14

    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
      Mifuyne
      2013-10-14

      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
    Earnie Boyd
    2013-10-15

    • status: unread --> closed
    • Resolution: none --> self-service
     
  • Earnie Boyd
    Earnie Boyd
    2013-10-15

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

     
  • TackyTexan
    TackyTexan
    2013-11-01

    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
    Keith Marshall
    2013-11-20

    • status: closed --> open
    • assigned_to: Earnie Boyd
    • Resolution: self-service --> none
     
  • Keith Marshall
    Keith Marshall
    2013-11-20

    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?

     

    Related

    Issues: #2139

    • TackyTexan
      TackyTexan
      2013-11-20

      $ 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
        Keith Marshall
        2013-11-20

        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
          TackyTexan
          2013-11-21

          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?

           
          Last edit: TackyTexan 2013-11-21
          • Keith Marshall
            Keith Marshall
            2013-11-22

            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.

             
  • 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
    David Grayson
    2013-12-17

    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.

     
    Last edit: David Grayson 2013-12-17
  • Eric D
    Eric D
    2013-12-18

    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
    Cesar Strauss
    2013-12-21

    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

     
    • 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

       
      Last edit: Keith Marshall 2013-12-21
      • Keith Marshall
        Keith Marshall
        2013-12-21

        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 Strauss
          2013-12-21

          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
            Keith Marshall
            2013-12-21

            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
        Cesar Strauss
        2013-12-21

        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

         
        • 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

           
          Attachments
          • Keith Marshall
            Keith Marshall
            2013-12-24

            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.

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

               
              Attachments
              • Keith Marshall
                Keith Marshall
                2013-12-26

                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.

                 
                • 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

                   
1 2 3 > >> (Page 1 of 3)