V in Cygwin, "direct.h" no such file

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • mrrstark
    Adept
    • Aug 2013
    • 101

    V in Cygwin, "direct.h" no such file

    Trying to compile on Cygwin (&MinGW) but getting this error:
    ...
    Successfully compiled z-bitflag.c.
    z-file.c:25:21: fatal error: direct.h: No such file or directory
    compilation terminated.
    Failed to compile z-file.c!

    This is from rephial nightlies.
    I followed these instructions in compiling.txt

    Using Cygwin (with MinGW)
    -------------------------

    Use this option if you want to build a native Windows executable that
    can run with or without Cygwin.

    Use the Cygwin setup.exe to install the mingw-gcc-core package and any
    dependencies suggested by the installer.

    Run these commands:

    ./autogen.sh
    ./configure --enable-win --with-no-install --host=i686-pc-mingw32
    make
  • FunkyGibbon
    Rookie
    • Dec 2013
    • 3

    #2
    Lurker turned Poster

    I've looked at the source, turns out whoever is committing that file is using (most likely) DMC to compile (digital mars compiler) only that set has this 'direct.h' file and it is NOT POSIX or FOS compliant, it will not compile on any GCC compiler on Linux, Windows or OSX.

    Strip that include 'direct.h' out and it should compile fine and without errors.

    A note: Why is a non-FOS compiler being used in an Open Source project? DMC is only freeware and only on Windows.

    Comment

    • takkaria
      Veteran
      • Apr 2007
      • 1951

      #3
      Originally posted by FunkyGibbon
      Lurker turned Poster

      I've looked at the source, turns out whoever is committing that file is using (most likely) DMC to compile (digital mars compiler) only that set has this 'direct.h' file and it is NOT POSIX or FOS compliant, it will not compile on any GCC compiler on Linux, Windows or OSX.

      Strip that include 'direct.h' out and it should compile fine and without errors.

      A note: Why is a non-FOS compiler being used in an Open Source project? DMC is only freeware and only on Windows.
      I don't think anyone is using DMC. That line works fine with mingw - it's a standard Windows hedaer - just not on cygwin.
      takkaria whispers something about options. -more-

      Comment

      • FunkyGibbon
        Rookie
        • Dec 2013
        • 3

        #4
        Ah! I wasn't aware it was also a windows header, I've never seen it not even on windows.

        Perhaps a simple ifdef would be a good choice? Because to compile that on *nix you would have to strip out that include. And it would avoid these compilation issues with people on other OS's.

        #include (standard cross platform headers)

        #ifdef _WINDOWS
        #include direct.h (and other includes needed)
        #else
        #include (same includes but won't include direct.h)
        #endif

        Comment

        • takkaria
          Veteran
          • Apr 2007
          • 1951

          #5
          Originally posted by FunkyGibbon
          Ah! I wasn't aware it was also a windows header, I've never seen it not even on windows.

          Perhaps a simple ifdef would be a good choice? Because to compile that on *nix you would have to strip out that include. And it would avoid these compilation issues with people on other OS's.

          #include (standard cross platform headers)

          #ifdef _WINDOWS
          #include direct.h (and other includes needed)
          #else
          #include (same includes but won't include direct.h)
          #endif

          If you look in the file, this is already there.
          takkaria whispers something about options. -more-

          Comment

          • FunkyGibbon
            Rookie
            • Dec 2013
            • 3

            #6
            Well I see the problem, there are only ifdefs for Windows, none for Linux and none for Cygwin and none for OS X, so all it is doing is checking if it is Windows, if it is not there are no ifdefs to prevent any other OS from not including direct.h. Maybe something in the makefile also? (I like to use IDE's not a makefile).

            #ifdef WINDOWS
            # include <windows.h>
            # include <io.h>
            # include <direct.h>
            #elif __GNU_LINUX__
            # include (all includes without windows specific)
            #elif __CYGWIN__
            # include (all includes with windows specific headers but without direct.h)
            #elif __APPLE__ && __MACH__
            # include (all includes without windows specific, probably same as Linux includes)
            #endif

            That would probably solve the issue, though I am no where near my Mac to try it. I am quite used to using single batch ifdefs, especially when compiling code written by mostly Windows using or MinGW using developers. I usually do it this way and I don't have problems.

            The main issue is that the direct.h handles the mkdir and so *nix cannot 'mkdir' unless it hits this code below the ifdef. It seems to just fail when hitting the direct.h and it does not look like the compiler gives 2 hoots about the windows ifdef.

            Just my 2 cents
            Last edited by FunkyGibbon; December 3, 2013, 13:22.

            Comment

            • takkaria
              Veteran
              • Apr 2007
              • 1951

              #7
              Originally posted by FunkyGibbon
              Well I see the problem, there are only ifdefs for Windows, none for Linux and none for Cygwin and none for OS X, so all it is doing is checking if it is Windows, if it is not there are no ifdefs to prevent any other OS from not including direct.h. Maybe something in the makefile also? (I like to use IDE's not a makefile).

              #ifdef WINDOWS
              # include <windows.h>
              # include <io.h>
              # include <direct.h>
              #elif __GNU_LINUX__
              # include (all includes without windows specific)
              #elif __CYGWIN__
              # include (all includes with windows specific headers but without direct.h)
              #elif __APPLE__ && __MACH__
              # include (all includes without windows specific, probably same as Linux includes)
              #endif

              That would probably solve the issue, though I am no where near my Mac to try it. I am quite used to using single batch ifdefs, especially when compiling code written by mostly Windows using or MinGW using developers. I usually do it this way and I don't have problems

              Just my 2 cents
              If you look a bit more closely, you'll see that there are HAVE_*_H ifdef chunks around the relevant header includes. These are set up by either h-basic.h or autoconf or the makefile depending on the platform. The things we want to include are not based on platform but on header file availability, which is what the current setup does.

              Obviously we need to stop direct.h being included if we're in cygwin and make sure that HAVE_DIRENT_H is defined in the makefile instead. But we already do what you're suggesting, we just need to tweak it.
              takkaria whispers something about options. -more-

              Comment

              • mrrstark
                Adept
                • Aug 2013
                • 101

                #8
                So for cygwin, can I just comment out the direct.h, or define something to finish the compilation?


                I also tried a MinGW shell compile, following the instructions in compiling.txt, but I got some other error, and no files compiled at all. I'm not at home atm, so can't provide the error message here. Is it expected to work as in compiling.txt?

                Comment

                • Nick
                  Vanilla maintainer
                  • Apr 2007
                  • 9634

                  #9
                  Originally posted by mrrstark
                  I also tried a MinGW shell compile, following the instructions in compiling.txt, but I got some other error, and no files compiled at all. I'm not at home atm, so can't provide the error message here. Is it expected to work as in compiling.txt?
                  In MinGW, I just use
                  Code:
                  MINGW=yes make -f Makefile.win
                  from the src directory.
                  One for the Dark Lord on his dark throne
                  In the Land of Mordor where the Shadows lie.

                  Comment

                  • mrrstark
                    Adept
                    • Aug 2013
                    • 101

                    #10
                    Originally posted by Nick
                    In MinGW, I just use
                    Code:
                    MINGW=yes make -f Makefile.win
                    from the src directory.
                    Awesome. That worked.

                    Comment

                    • MattB
                      Veteran
                      • Mar 2013
                      • 1214

                      #11
                      I'm not really sure why, but I always read every line of these posts, and I genuinely haven't understood a single word so far! Must be the Angband effect, I guess...

                      Comment

                      • AnonymousHero
                        Veteran
                        • Jun 2007
                        • 1393

                        #12
                        Originally posted by MattB
                        I'm not really sure why, but I always read every line of these posts, and I genuinely haven't understood a single word so far! Must be the Angband effect, I guess...
                        I think it's the Lack of Arcane Knowledge That Should Be Mostly Useless for Anyone Developing Software By Now, but Regretfully Isn't. I call it the LoAKTSBMUfADSBNbRI principle, but unfortunately that term hasn't caught on.

                        ... but take heart and don't fret! Soon such "knowledge" won't be required!

                        Comment

                        Working...
                        😀
                        😂
                        🥰
                        😘
                        🤢
                        😎
                        😞
                        😡
                        👍
                        👎