Loading ...
Sorry, an error occurred while loading the content.

Re: Compile 6.0ap under Cygwin

Expand Messages
  • Corinna Vinschen
    ... Ok, got it. It s a buggy implementation of fchdir() in Cygwin which doesn t correctly handle changing to relative paths under all circumstances. Since I
    Message 1 of 22 , Aug 1, 2001
    • 0 Attachment
      On Wed, Aug 01, 2001 at 09:16:21PM +0200, Corinna Vinschen wrote:
      > I began to debug that and it's not related to backslash issues.
      > It has something to do with fchdir() but I haven't got what the
      > whole function `os_unix.c::mch_FullName()' is doing. It has called
      > a fchdir() which returned 0 (and actually has changed the cwd) but
      > a few lines later it calls mch_chdir() which again tries to chdir
      > to the same directory which obviously failes now... As I said, I'm
      > not in a state where I actually understand the code here...

      Ok, got it. It's a buggy implementation of fchdir() in Cygwin
      which doesn't correctly handle changing to relative paths under
      all circumstances. Since I have implemented fchdir() in Cygwin
      I have to blame myself.

      Probably it would be the best way to stuck with chdir() (not
      defining HAVE_FCHDIR for Cygwin even if the function is
      available) for two reasons.

      - fchdir() is currently implemented only in the Cygwin developer
      snapshots. Even the current official Cygwin release (1.3.2)
      doesn't have it.
      - It's incorrect as aforementioned. I have to rethink the implementation
      somehow...

      Corinna

      --
      Corinna Vinschen
      Cygwin Developer
      Red Hat, Inc.
      mailto:vinschen@...
    • Bram Moolenaar
      Dan - ... Thanks for verifying that. I can imagine the OLE version needs some extra header files. gui_w48 must also use something that requires an extra
      Message 2 of 22 , Aug 1, 2001
      • 0 Attachment
        Dan -

        > >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In
        > >several files where windows.h is included it is used, in others it is not.
        > >What is the rule for using it?
        >
        > I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of
        > every call to #include <windows.h> and it breaks compilation of if_ole.cpp
        > and gui_w48.c. Removing it from if_ole.cpp fixed that problem, and
        > removing it from gui.h fixed the gui_w48.c problem (removing it from
        > gui_w48.c didn't help. I guess since it was already done in gui.h, the
        > #include <windows.h> in gui_w48.c is a little redundant, at least for
        > win32). It looks like the idea behind it is to speed up compilation time
        > by not reading in the lesser used header files. I didn't see any change in
        > code size, and didn't really pay attention to compile time differences.

        Thanks for verifying that. I can imagine the OLE version needs some extra
        header files. gui_w48 must also use something that requires an extra header
        file (resolving the .lnk file perhaps?).

        I'll include the define in the places where it's possible, not in a global
        place. Will do some more testing later (it might depend on the features
        included).

        - Bram

        --
        hundred-and-one symptoms of being an internet addict:
        103. When you find yourself in the "Computer" section of Barnes & Noble
        enjoying yourself.

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Bram Moolenaar
        ... mch_FullName() expands a path name to an absolute path. Thus it becomes independent of changing directory. The fchdir() doesn t change directory the first
        Message 3 of 22 , Aug 1, 2001
        • 0 Attachment
          Corinna Vinschen wrote:

          > I began to debug that and it's not related to backslash issues.
          > It has something to do with fchdir() but I haven't got what the
          > whole function `os_unix.c::mch_FullName()' is doing. It has called
          > a fchdir() which returned 0 (and actually has changed the cwd) but
          > a few lines later it calls mch_chdir() which again tries to chdir
          > to the same directory which obviously failes now... As I said, I'm
          > not in a state where I actually understand the code here...

          mch_FullName() expands a path name to an absolute path. Thus it becomes
          independent of changing directory.

          The fchdir() doesn't change directory the first time, it's used to remember
          the current directory ".". The mch_chdir() then changes directory and another
          fchdir() takes us back to the old current directory. This works fine on Unix,
          perhaps the special handling of directories under Cygwin has some problems
          with this construction.

          > > I wonder how you make symlinks at all, since Windows doesn't have them. I
          > > have cygwin 1.0, but I can't find a reference to symlinks.
          >
          > The current Cygwin 1.3.2 version can create symlinks in two
          > different ways. The old method (already supported by 1.0)
          > creates regular files with a special content (a magic cookie
          > and the actual target path) and which has the `system' bit
          > set in the file attributes. This type of symlinks is only
          > recognized by native Cygwin apps.

          Ah, a trick. That doesn't explain why the ".exe" can't be added though.

          > The second way is by creating Windows shortcuts (*.lnk files)
          > with a special content and the R/O bit set. Native Cygwin apps
          > will not see the .lnk extension and native Windows apps are
          > able to use the links as normal Windows shortcuts.

          Even more complicated trick (the .lnk file format is undocumented, at least we
          couldn't find it). I suppose that .lnk extention is the reason we can't use
          .exe.

          --
          hundred-and-one symptoms of being an internet addict:
          104. When people ask about the Presidential Election you ask "Which country?"

          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
          ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
        • Denis (work)
          ..snip.. ... ..snip.. ... ah, i would pay to have some ms windows programmers around here, and hear them say something similar about some things in that other
          Message 4 of 22 , Aug 1, 2001
          • 0 Attachment
            ..snip..

            | Since I have implemented fchdir() in Cygwin
            | I have to blame myself.


            ..snip..

            | - It's incorrect as aforementioned. I have to rethink the implementation
            | somehow...


            ah, i would pay to have some ms windows programmers around
            here, and hear them say something similar about some things
            in that other OS :)

            denis

            ps. dont get me wrong, i like windows and all...

            --

            /*
            * Denis Perelyubskiy
            * icq : 12359698
            * mailto: denisp@...
            * PGP : http://www.cs.ucla.edu/~denisp/files/pgp.asc
            */
          • Corinna Vinschen
            ... You can read and write them using COM functions. ... Sorry if that was unclear in my first mail. The .exe extensions are no problem anymore for the current
            Message 5 of 22 , Aug 1, 2001
            • 0 Attachment
              On Wed, Aug 01, 2001 at 10:43:13PM +0200, Bram Moolenaar wrote:
              > > The second way is by creating Windows shortcuts (*.lnk files)
              > > with a special content and the R/O bit set. Native Cygwin apps
              > > will not see the .lnk extension and native Windows apps are
              > > able to use the links as normal Windows shortcuts.
              >
              > Even more complicated trick (the .lnk file format is undocumented, at least we
              > couldn't find it).

              You can read and write them using COM functions.

              > I suppose that .lnk extention is the reason we can't use
              > .exe.

              Sorry if that was unclear in my first mail. The .exe extensions
              are no problem anymore for the current implementation of the symlink
              code but IIRC they were a problem a few months ago and they are
              somehow *gulp* unaesthetic. The symlinks to executables don't
              have a .exe suffix in the whole net distro, so...

              Corinna

              --
              Corinna Vinschen
              Cygwin Developer
              Red Hat, Inc.
              mailto:vinschen@...
            • Corinna Vinschen
              ... Hey, I like Windows NT/W2K as it is! I wouldn t have that fun working on Cygwin if Windows would be perfect ;-) OTOH, don t talk about 9x/ME... Corinna --
              Message 6 of 22 , Aug 1, 2001
              • 0 Attachment
                On Wed, Aug 01, 2001 at 01:54:53PM -0700, Denis (work) wrote:
                >
                > ..snip..
                >
                > | Since I have implemented fchdir() in Cygwin
                > | I have to blame myself.
                >
                >
                > ..snip..
                >
                > | - It's incorrect as aforementioned. I have to rethink the implementation
                > | somehow...
                >
                >
                > ah, i would pay to have some ms windows programmers around
                > here, and hear them say something similar about some things
                > in that other OS :)
                >
                > denis
                >
                > ps. dont get me wrong, i like windows and all...

                Hey, I like Windows NT/W2K as it is! I wouldn't have that fun
                working on Cygwin if Windows would be perfect ;-)

                OTOH, don't talk about 9x/ME...

                Corinna

                --
                Corinna Vinschen
                Cygwin Developer
                Red Hat, Inc.
                mailto:vinschen@...
              • Thore B. Karlsen
                ... But they do, maybe not so often in public, but they do. When I was up at Microsoft the developers weren t brainwashed to the extent one would think. The
                Message 7 of 22 , Aug 1, 2001
                • 0 Attachment
                  On Wed, 1 Aug 2001 13:54:53 -0700, you wrote:

                  >| - It's incorrect as aforementioned. I have to rethink the implementation
                  >| somehow...

                  >ah, i would pay to have some ms windows programmers around
                  >here, and hear them say something similar about some things
                  >in that other OS :)

                  But they do, maybe not so often in public, but they do. When I was up at
                  Microsoft the developers weren't brainwashed to the extent one would
                  think. The users, on the other hand. :)
                • Corinna Vinschen
                  ... I have further investigated that problem and I have fixed fchdir() in the Cygwin CVS repository. However, since the current official and previous releases
                  Message 8 of 22 , Aug 3, 2001
                  • 0 Attachment
                    On Wed, Aug 01, 2001 at 10:31:38PM +0200, Corinna Vinschen wrote:
                    > Ok, got it. It's a buggy implementation of fchdir() in Cygwin
                    > which doesn't correctly handle changing to relative paths under
                    > all circumstances. Since I have implemented fchdir() in Cygwin
                    > I have to blame myself.
                    >
                    > Probably it would be the best way to stuck with chdir() (not
                    > defining HAVE_FCHDIR for Cygwin even if the function is
                    > available) for two reasons.
                    >
                    > - fchdir() is currently implemented only in the Cygwin developer
                    > snapshots. Even the current official Cygwin release (1.3.2)
                    > doesn't have it.
                    > - It's incorrect as aforementioned. I have to rethink the implementation
                    > somehow...

                    I have further investigated that problem and I have fixed fchdir()
                    in the Cygwin CVS repository. However, since the current official
                    and previous releases don't have fchdir() at all, I think it's better
                    to not use fchdir() for Cygwin to keep backward compatibility.

                    For that reason I would like to propose the following patch to
                    `configure.in' which results in skipping the fchdir check when
                    configuring for Cygwin:

                    --- configure.in.ORIG Fri Aug 3 13:16:07 2001
                    +++ configure.in Fri Aug 3 13:15:57 2001
                    @@ -59,6 +59,13 @@ case `uname` in
                    QNX=no; AC_MSG_RESULT(no);;
                    esac

                    +dnl If Cygwin is found, assume we don't want to use fchdir to be
                    +dnl backward compatible to versions before 1.3.3
                    +AC_MSG_CHECKING(for Cygwin)
                    +case `uname` in
                    + CYGWIN*) ac_cv_func_fchdir=no;;
                    +esac
                    +
                    AC_SUBST(OS_EXTRA_SRC)
                    AC_SUBST(OS_EXTRA_OBJ)


                    Corinna

                    --
                    Corinna Vinschen
                    Cygwin Developer
                    Red Hat, Inc.
                    mailto:vinschen@...
                  • Bram Moolenaar
                    ... OK. But it s a bit strange to do this in configure. I rather do this in vim.h. How about this instead: ... *************** ... # if (SIZEOF_INT == 0)
                    Message 9 of 22 , Aug 3, 2001
                    • 0 Attachment
                      Corinna Vinschen wrote:

                      > I have further investigated that problem and I have fixed fchdir()
                      > in the Cygwin CVS repository. However, since the current official
                      > and previous releases don't have fchdir() at all, I think it's better
                      > to not use fchdir() for Cygwin to keep backward compatibility.
                      >
                      > For that reason I would like to propose the following patch to
                      > `configure.in' which results in skipping the fchdir check when
                      > configuring for Cygwin:

                      OK. But it's a bit strange to do this in configure. I rather do this in
                      vim.h. How about this instead:

                      *** vim.h~ Fri Aug 3 15:55:26 2001
                      --- vim.h Fri Aug 3 17:41:05 2001
                      ***************
                      *** 37,42 ****
                      --- 37,49 ----
                      # if (SIZEOF_INT == 0)
                      Error: configure did not run properly. Check auto/config.log.
                      # endif
                      +
                      + /*
                      + * Cygwin may have fchdir(), but in most versions it doesn't work well.
                      + */
                      + # if defined(__CYGWIN32__) && defined(HAVE_FCHDIR)
                      + # undef HAVE_FCHDIR
                      + # endif
                      #endif

                      #ifdef __EMX__ /* hand-edited config.h for OS/2 with EMX */

                      --
                      hundred-and-one symptoms of being an internet addict:
                      145. You e-mail your boss, informing him you'll be late.

                      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                      ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                    • Corinna Vinschen
                      ... I m usually trying to solve such problems in the configuring to minimize target dependent code. If you like the below solution more, that s ok with me. I
                      Message 10 of 22 , Aug 3, 2001
                      • 0 Attachment
                        On Fri, Aug 03, 2001 at 05:49:24PM +0200, Bram Moolenaar wrote:
                        > OK. But it's a bit strange to do this in configure. I rather do this in
                        > vim.h. How about this instead:

                        I'm usually trying to solve such problems in the configuring to
                        minimize target dependent code. If you like the below solution
                        more, that's ok with me. I would like to see another comment,
                        though. As I said, fchdir() is only implemented in the developers
                        version and not in an official release. So not using fchdir()
                        is mainly to keep backward compatibility even if the next Cygwin
                        release is out. And, btw., due to restrictions of the Win32 API
                        the fchdir() function is actually slower than chdir()...

                        Corinna

                        >
                        > *** vim.h~ Fri Aug 3 15:55:26 2001
                        > --- vim.h Fri Aug 3 17:41:05 2001
                        > ***************
                        > *** 37,42 ****
                        > --- 37,49 ----
                        > # if (SIZEOF_INT == 0)
                        > Error: configure did not run properly. Check auto/config.log.
                        > # endif
                        > +
                        > + /*
                        > + * Cygwin may have fchdir(), but in most versions it doesn't work well.

                        + * Only newer Cygwin releases have fchdir(). We don't use it to
                        + * keep the binary backward compatible.

                        > + */
                        > + # if defined(__CYGWIN32__) && defined(HAVE_FCHDIR)
                        > + # undef HAVE_FCHDIR
                        > + # endif
                        > #endif
                        >
                        > #ifdef __EMX__ /* hand-edited config.h for OS/2 with EMX */
                        >
                        > --
                        > hundred-and-one symptoms of being an internet addict:
                        > 145. You e-mail your boss, informing him you'll be late.
                        >
                        > /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                        > ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                        > \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///

                        --
                        Corinna Vinschen
                        Cygwin Developer
                        Red Hat, Inc.
                        mailto:vinschen@...
                      Your message has been successfully submitted and would be delivered to recipients shortly.