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

Re: VIM7: Error building snapshot (CVS 2/26 9:00PM CST)

Expand Messages
  • Antoine J. Mechelynck
    ... Hmm... All I can say is I don t see this error when compiling for native W32 using cygwin gcc and Make_cyg.mak (I intentionally compiled the new snapshot
    Message 1 of 10 , Feb 26, 2005
    • 0 Attachment
      Johnny Blaze wrote:
      > I got the following error message trying to build the source retreived
      > from CVS @ 2/26 9:00PM CST:
      >
      >
      > ex_cmds2.obj : error LNK2019: unresolved external symbol _gettimeofday
      > referenced in function _profile_start
      > gvim.exe : fatal error LNK1120: 1 unresolved externals
      > NMAKE : fatal error U1077: 'link' : return code '0x460'
      > Stop.
      >
      > There was also a error earlier on, and it said no prototype for
      > _getttimeofday, assuming extern returning int
      >
      > Command Line:
      > nmake -f Make_mvc.mak GUI=yes OLE=yes PERL=c:\perl DYNAMIC_PERL=yes
      > PERL_VER=58 IME=yes CSCOPE=yes FEATURES=HUGE CPUNR=pentium4 all
      >
      > MSVC 7.1 (2003), WinXP
      >
      Hmm...
      All I can say is I don't see this error when compiling for native W32
      using cygwin gcc and Make_cyg.mak (I intentionally compiled the new
      snapshot before answering).

      I seem to remember that someone else also had problems recently due to
      incompletely patched sources (but for 6.3). Wasn't he using CVS too? I
      get the snapshots in zip format from
      ftp://ftp.vim.org/pub/vim/unstable/snapshot/ .

      You can get my make log (202 KB) and/or my compiling script (for cygwin
      bash, 573 bytes) if you want to but I'm not posting them to the list
      because of bulk and limited interest value.

      My newly compiled binaries have just been posted, the link is at
      http://users.skynet.be/antoine.mechelynck/vim/#vim7 . (Read the
      disclaimer before deciding if you want to download.) They have (among
      others) features=BIG +w32 +/-(gui && ole) +/-debug +mzscheme/dyn
      +perl/dyn(perl58.dll) +python/dyn +ruby/dyn +tcl/dyn +multi_byte_ime/dyn
      +cscope (using +/- because 4 executables are included): they ought to
      give the functionality you need but maybe also some not-really-harmful
      bloat you don't really need. IIUC they are linked to the MSVC shared
      libraries so that shouldn't be a problem either.

      - Are you sure you got everything?
      - I see a definition for gettimeofday in main.c following "# ifdef
      WIN3264" at line 2853. (That copy of main.c is dated Feb 25 14:48 in my
      directory listing.) Here it is (it comes at the end of another #ifdef
      range, namely "#if defined(STARTUPTIME) || defined(PROTO)" at line 2760):

      # ifdef WIN3264
      /*
      * Windows doesn't have gettimeofday(), although it does have struct
      timeval.
      */
      int
      gettimeofday(struct timeval *tv, char *dummy)
      {
      long t = clock();
      tv->tv_sec = t / CLOCKS_PER_SEC;
      tv->tv_usec = (t - tv->tv_sec * CLOCKS_PER_SEC) * 1000000 /
      CLOCKS_PER_SEC;
      return 0;
      }
      # endif




      Best regards,
      Tony.
    • Bram Moolenaar
      ... The new profiling function needs the gettimeofday() function. I forgot to add the #ifdefs for it. This patch should help: ... *************** *** 382,388
      Message 2 of 10 , Feb 27, 2005
      • 0 Attachment
        Johnny Blaze wrote:

        > I got the following error message trying to build the source retreived
        > from CVS @ 2/26 9:00PM CST:
        >
        > ex_cmds2.obj : error LNK2019: unresolved external symbol _gettimeofday
        > referenced in function _profile_start
        > gvim.exe : fatal error LNK1120: 1 unresolved externals
        > NMAKE : fatal error U1077: 'link' : return code '0x460'
        > Stop.
        >
        > There was also a error earlier on, and it said no prototype for
        > _getttimeofday, assuming extern returning int
        >
        > Command Line:
        > nmake -f Make_mvc.mak GUI=yes OLE=yes PERL=c:\perl DYNAMIC_PERL=yes
        > PERL_VER=58 IME=yes CSCOPE=yes FEATURES=HUGE CPUNR=pentium4 all
        >
        > MSVC 7.1 (2003), WinXP

        The new profiling function needs the gettimeofday() function. I forgot
        to add the #ifdefs for it. This patch should help:


        *** src/feature.h.orig Fri Feb 25 14:49:39 2005
        --- src/feature.h Sun Feb 27 12:29:28 2005
        ***************
        *** 382,388 ****
        /*
        * +profile Profiling for functions and scripts.
        */
        ! #ifdef FEAT_HUGE
        # define FEAT_PROFILE
        #endif

        --- 382,388 ----
        /*
        * +profile Profiling for functions and scripts.
        */
        ! #if defined(FEAT_HUGE) && defined(HAVE_GETTIMEOFDAY) && defined(HAVE_SYS_TIME_H)
        # define FEAT_PROFILE
        #endif

        But we should actually look for a good timing function that works on
        Win32.

        --
        The term "free software" is defined by Richard M. Stallman as
        being software that isn't necessarily for free. Confusing?
        Let's call it "Stallman software" then!
        -- Bram Moolenaar

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
      • Bill McCarthy
        ... Thanks Bram, after reading Johnny Blase s report I didn t bother trying with Ming. After patching feature.h, Make_ming.mak built v7-0052 flawlessly -
        Message 3 of 10 , Feb 27, 2005
        • 0 Attachment
          On Sun 27-Feb-05 6:19am -0600, Bram Moolenaar wrote:

          > The new profiling function needs the gettimeofday()
          > function. I forgot to add the #ifdefs for it. This
          > patch should help:

          Thanks Bram, after reading Johnny Blase's report I
          didn't bother trying with Ming.

          After patching feature.h, Make_ming.mak built v7-0052
          flawlessly - albeit without the new `profile` feature.

          Bram or any CVS expert: Having patched feature.h in my
          local CVS files copy, I will now get something like:

          M src/feature.h

          whenever I run CVS again. That is, I won't know when
          it is updated again. Is this true?

          As a workaround, I'm keeping a feature.h.new (patched)
          and feature.h.orig (unpatched) so if I see other
          changes, I can delete feature.h, rerun CVS and compare
          the downloaded feature.h to my extra files.

          Is this how others deal with such patches?

          --
          Best regards,
          Bill
        • George V. Reilly
          ... Try QueryPerformanceCounter(). On x86, it s more or less a wrapper around RDTSC. -- Some people like my advice so much that they frame it upon the wall
          Message 4 of 10 , Feb 27, 2005
          • 0 Attachment
            Bram Moolenaar wrote:

            >The new profiling function needs the gettimeofday() function. I forgot
            >to add the #ifdefs for it. This patch should help:
            >
            >[...]
            >
            >But we should actually look for a good timing function that works on
            >Win32.
            >

            Try QueryPerformanceCounter(). On x86, it's more or less a wrapper
            around RDTSC.

            --
            Some people like my advice so much that they frame it upon the wall
            instead of using it.
            -- Gordon R. Dickson
            (Get Witty Auto-Generated Signatures from http://SmartBee.org)
            George V. Reilly george@...
            http://george.reilly.org/
            Read my blog: http://weblogs.asp.net/george_v_reilly/
          • Antoine J. Mechelynck
            ... Mostly I limit myself to official v6.3 patches and official v7 snapshots. If I need to test-compile with a patch available only by mail (and which
            Message 5 of 10 , Feb 27, 2005
            • 0 Attachment
              Bill McCarthy wrote:
              > On Sun 27-Feb-05 6:19am -0600, Bram Moolenaar wrote:
              >
              >
              >>The new profiling function needs the gettimeofday()
              >>function. I forgot to add the #ifdefs for it. This
              >>patch should help:
              >
              >
              > Thanks Bram, after reading Johnny Blase's report I
              > didn't bother trying with Ming.
              >
              > After patching feature.h, Make_ming.mak built v7-0052
              > flawlessly - albeit without the new `profile` feature.
              >
              > Bram or any CVS expert: Having patched feature.h in my
              > local CVS files copy, I will now get something like:
              >
              > M src/feature.h
              >
              > whenever I run CVS again. That is, I won't know when
              > it is updated again. Is this true?
              >
              > As a workaround, I'm keeping a feature.h.new (patched)
              > and feature.h.orig (unpatched) so if I see other
              > changes, I can delete feature.h, rerun CVS and compare
              > the downloaded feature.h to my extra files.
              >
              > Is this how others deal with such patches?
              >
              Mostly I limit myself to "official" v6.3 patches and "official" v7
              snapshots. If I need to test-compile with a patch available only by mail
              (and which might or might not be included in the next "official" patch)
              I patch before compiling, reverse the patch after compiling, and I don't
              move the resulting binary/ies from my "development" directory (such as
              $HOME/devel/vim/vim70aa/src) to my "production" directory (such as
              $VIM/vim70aa).

              Some time ago I used to compile with an unofficial patch (Vince Negri's
              conceal/ownsyntax); in that case I patched once, kept it patched, and
              didn't worry about "official" patches matching with a line offset -- as
              long as they matched somewhere. But I had to reverse that patch because
              it was incompatible with "official" patches 6.3.29 and later.

              I don't use CVS, however; I get the patches and snapshots the
              old-fashioned way -- by FTP, using an FTP client for 6.3 patches and a
              web browser for 7.00aa snapshots.

              Best regards,
              Tony.
            • Bram Moolenaar
              ... It s because Johnny uses FEATURES=HUGE. That enables the profiling feature. ... This is only used for startup timing. We could use it for profiling, but
              Message 6 of 10 , Feb 27, 2005
              • 0 Attachment
                Antoine Mechelynck wrote:

                > > There was also a error earlier on, and it said no prototype for
                > > _getttimeofday, assuming extern returning int
                > >
                > > Command Line:
                > > nmake -f Make_mvc.mak GUI=yes OLE=yes PERL=c:\perl DYNAMIC_PERL=yes
                > > PERL_VER=58 IME=yes CSCOPE=yes FEATURES=HUGE CPUNR=pentium4 all
                > >
                > > MSVC 7.1 (2003), WinXP
                > >
                > Hmm...
                > All I can say is I don't see this error when compiling for native W32
                > using cygwin gcc and Make_cyg.mak (I intentionally compiled the new
                > snapshot before answering).

                It's because Johnny uses FEATURES=HUGE. That enables the profiling
                feature.

                > - Are you sure you got everything?
                > - I see a definition for gettimeofday in main.c following "# ifdef
                > WIN3264" at line 2853. (That copy of main.c is dated Feb 25 14:48 in my
                > directory listing.) Here it is (it comes at the end of another #ifdef
                > range, namely "#if defined(STARTUPTIME) || defined(PROTO)" at line 2760):

                This is only used for startup timing. We could use it for profiling,
                but it's not very accurate. Isn't there something better than clock()
                on MS-Windows?

                Hmm, some Googling suggests that QueryPerformanceCounter() and
                QueryPerformanceFrequency() should give the best results. Does someone
                have experience with them?

                --
                hundred-and-one symptoms of being an internet addict:
                237. You tattoo your email address on your forehead.

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
              • Bram Moolenaar
                ... OK. The docs mention that QueryPerformanceCounter() may not work on all systems. That s a bit strange, I thought most PCs have the same hardware. --
                Message 7 of 10 , Feb 27, 2005
                • 0 Attachment
                  George Reilly wrote:

                  > >The new profiling function needs the gettimeofday() function. I forgot
                  > >to add the #ifdefs for it. This patch should help:
                  > >
                  > >[...]
                  > >
                  > >But we should actually look for a good timing function that works on
                  > >Win32.
                  > >
                  >
                  > Try QueryPerformanceCounter(). On x86, it's more or less a wrapper
                  > around RDTSC.

                  OK. The docs mention that QueryPerformanceCounter() may not work on all
                  systems. That's a bit strange, I thought most PCs have the same
                  hardware.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  243. You unsuccessfully try to download a pizza from www.dominos.com.

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                  \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                • George V. Reilly
                  ... Really old systems with strange BIOSes might give anomalous results. But you likely have bigger problems in that case. And on some old multiprocessor
                  Message 8 of 10 , Feb 27, 2005
                  • 0 Attachment
                    Bram Moolenaar wrote:

                    >George Reilly wrote:
                    >
                    >
                    >>>The new profiling function needs the gettimeofday() function. I forgot
                    >>>to add the #ifdefs for it. This patch should help:
                    >>>
                    >>>[...]
                    >>>
                    >>>But we should actually look for a good timing function that works on
                    >>>Win32.
                    >>>
                    >>>
                    >>>
                    >>Try QueryPerformanceCounter(). On x86, it's more or less a wrapper
                    >>around RDTSC.
                    >>
                    >>
                    >
                    >OK. The docs mention that QueryPerformanceCounter() may not work on all
                    >systems. That's a bit strange, I thought most PCs have the same
                    >hardware.
                    >
                    >

                    Really old systems with strange BIOSes might give anomalous results. But
                    you likely have bigger problems in that case. And on some old
                    multiprocessor systems, you may get non-monotonically increasing
                    results, if your thread is scheduled on different processors.

                    >Hmm, some Googling suggests that QueryPerformanceCounter() and
                    >QueryPerformanceFrequency() should give the best results. Does someone
                    >have experience with them?
                    >
                    >

                    Yes, they work well. On systems that are trying to conserve power, e.g.,
                    laptops running on batteries, you may get inconsistent results if the
                    system dynamically adjusts the processor frequency between readings. If
                    you're running at 100% CPU utilization, however, that's quite unlikely.
                    Of course, you'll also get inconsistent results if the system is
                    spending significant cycles on other processes while you're profiling.

                    Bottom line: QPC is quick, cheap, reliable, high-resolution, and
                    portable across Windows.

                    --
                    Access to computers, and anything which might teach you comething
                    about the way the world workd, should be unlimited and total.
                    Always yield to the Hands-On imperative.
                    -- Steven Levy
                    (Get Witty Auto-Generated Signatures from http://SmartBee.org)
                    George V. Reilly george@...
                    http://george.reilly.org/
                    Read my blog: http://weblogs.asp.net/george_v_reilly/
                  • jamessan@jamessan.com
                    ... You will know when it has been updated. If there is a new revision in CVS when you perform an update, CVS will say something about merging the two
                    Message 9 of 10 , Feb 28, 2005
                    • 0 Attachment
                      On Sun, Feb 27, 2005 at 10:46:29AM -0600, Bill McCarthy wrote:
                      >
                      > [snip]
                      >
                      > Bram or any CVS expert: Having patched feature.h in my
                      > local CVS files copy, I will now get something like:
                      >
                      > M src/feature.h
                      >
                      > whenever I run CVS again. That is, I won't know when
                      > it is updated again. Is this true?

                      You will know when it has been updated. If there is a new revision in
                      CVS when you perform an update, CVS will say something about merging the
                      two revisions. It will look something like:

                      $ cvs update driver.c
                      RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
                      retrieving revision 1.4
                      retrieving revision 1.6
                      Merging differences between 1.4 and 1.6 into driver.c

                      Depending on whether the merge was successful or not, the last couple
                      lines will vary. "M driver.c" indicates that everything worked fine.
                      "C driver.c" indicates that there were conflicts which need to be
                      resolved. You can also use the "cvs diff" command to compare your local
                      copy to what the server has as its current copy.

                      > As a workaround, I'm keeping a feature.h.new (patched)
                      > and feature.h.orig (unpatched) so if I see other
                      > changes, I can delete feature.h, rerun CVS and compare
                      > the downloaded feature.h to my extra files.
                      >
                      > Is this how others deal with such patches?

                      I tend to keep changes as is and let CVS tell me when things change. If
                      a conflict does occur, CVS will make a copy of your original local copy
                      as .#driver.c.1.4 (from the example above) and the current driver.c will
                      denote what conflicts need to be looked at.

                      Some useful URLs:
                      CVS Manual:
                      https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs.html
                      Description of the output from cvs update:
                      https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_16.html#SEC156
                      Example of a conflict:
                      https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_10.html#SEC85

                      James

                      --
                      GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                    Your message has been successfully submitted and would be delivered to recipients shortly.