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

Re: Can't build with Perl using Make_ming.mak any more [semi-solved]

Expand Messages
  • Christian J. Robinson
    On Thu, Feb 7, 2013 at 12:44 PM, Christian J. Robinson ... [...] ... I have determined that this error was because if_perl.c was zero length. I removed it and
    Message 1 of 7 , Feb 20, 2013
    • 0 Attachment
      On Thu, Feb 7, 2013 at 12:44 PM, Christian J. Robinson
      <heptite@...> wrote:
      >
      > I think one of the patches since 804 has broken something, because I
      > can't get a working gvim with Perl using Make_ming.mak--it fails
      > during linking:
      >
      > gobji386/buffer.o:buffer.c:(.text+0x10aa): undefined reference to `_perl_buf_free'
      [...]
      > collect2: ld returned 1 exit status
      > Make_ming.mak:683: recipe for target `gvim.exe' failed
      > make: *** [gvim.exe] Error 1

      I have determined that this error was because if_perl.c was zero
      length. I removed it and tried again, which produced these errors:

      perl /cygdrive/c/strawberry/perl/lib/ExtUtils/xsubpp -prototypes -typemap \
      /cygdrive/c/strawberry/perl/lib/ExtUtils/typemap if_perl.xs > if_perl.c
      Can't find /cygdrive/c/strawberry/perl/lib/ExtUtils/typemap in
      /home/Heptite/src/vim/src
      Make_ming.mak:757: recipe for target `if_perl.c' failed

      This led me to realizing that the rule for generating if_perl.c is
      broken when trying to build with Cygwin's mingw installation. The
      problem is that it leaves behind a zero length if_perl.c which is then
      assumed to be valid on later attempts to build, which is why I was
      getting the errors I originally posted.

      I had to change the if_perl.c rule in Make_ming.mak to the following
      to get a clean build:

      if_perl.c: if_perl.xs typemap
      $(XSUBPP) -prototypes -typemap \
      `cygpath -w $(PERLLIB)/ExtUtils/typemap` if_perl.xs > $@

      As you can see, cygwin likes Unix paths, but this is calling a native
      Windows Perl installation's xsubpp, which expects a native Windows
      pathname to typemap, so it has to be converted.

      This is not an optimal solution; I think there needs to be some kind
      of logic to allow people using Cygwin's mingw plus a native Windows
      Perl installation.

      I also had to tweak GvimExt/Make_ming.mak to change CXX from
      $(CROSS_COMPILE)g++-3 to $(CROSS_COMPILE)g++, in case anybody else
      is having troulble getting GvimExt to compile with a build environment
      similar to mine.

      - Christian

      --
      Christian J. Robinson <heptite@...>

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ken Takata
      Hi Christian, ... There are some solutions for this problem: 1. Use Make_cyg.mak instead of Make_ming.mak and use Unix-style paths: $ make -f Make_cyg.mak
      Message 2 of 7 , Feb 20, 2013
      • 0 Attachment
        Hi Christian,

        2013/02/21 Thu 5:33:45 UTC+9 Heptite wrote:

        > This led me to realizing that the rule for generating if_perl.c is
        > broken when trying to build with Cygwin's mingw installation. The
        > problem is that it leaves behind a zero length if_perl.c which is then
        > assumed to be valid on later attempts to build, which is why I was
        > getting the errors I originally posted.
        >
        > I had to change the if_perl.c rule in Make_ming.mak to the following
        > to get a clean build:
        >
        > if_perl.c: if_perl.xs typemap
        > $(XSUBPP) -prototypes -typemap \
        > `cygpath -w $(PERLLIB)/ExtUtils/typemap` if_perl.xs > $@
        >
        > As you can see, cygwin likes Unix paths, but this is calling a native
        > Windows Perl installation's xsubpp, which expects a native Windows
        > pathname to typemap, so it has to be converted.
        >
        > This is not an optimal solution; I think there needs to be some kind
        > of logic to allow people using Cygwin's mingw plus a native Windows
        > Perl installation.

        There are some solutions for this problem:

        1. Use Make_cyg.mak instead of Make_ming.mak and use Unix-style paths:

        $ make -f Make_cyg.mak PERL=/cygdrive/c/strawberry/perl

        2. Use Make_ming.mak and use Windows-like paths:

        $ make -f Make_ming.mak PERL=c:/strawberry/perl


        > I also had to tweak GvimExt/Make_ming.mak to change CXX from
        > $(CROSS_COMPILE)g++-3 to $(CROSS_COMPILE)g++, in case anybody else
        > is having troulble getting GvimExt to compile with a build environment
        > similar to mine.

        I think 'CXX=$(CROSS_COMPILE)g++' is the default.


        BTW, Make_cyg.mak and Make_ming.mak do the almost same thing.
        (Make_cyg.mak has a option 'USEDLL' which Make_ming.mak doesn't have,
        but USEDLL=yes doesn't seem to work anymore.)
        I'm wondering that Make_cyg.mak can be merged into Make_ming.mak.
        It's hard to maintain the two almost same files.

        Regards,
        Ken Takata

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Christian J. Robinson
        ... I used to build using Make_cyg.mak but stopped in recent months because it no longer worked for me when including one of the scripting interpreters. I
        Message 3 of 7 , Feb 20, 2013
        • 0 Attachment
          On Wed, 20 Feb 2013, Ken Takata wrote:

          > There are some solutions for this problem:
          >
          > 1. Use Make_cyg.mak instead of Make_ming.mak and use Unix-style paths:
          >
          > $ make -f Make_cyg.mak PERL=/cygdrive/c/strawberry/perl

          I used to build using Make_cyg.mak but stopped in recent months
          because it no longer worked for me when including one of the scripting
          interpreters. I include Perl, Python and Ruby, but I can't remember
          which broke. About the same time Make_ming.mak _started_ working for
          me when it didn't before.

          > 2. Use Make_ming.mak and use Windows-like paths:
          >
          > $ make -f Make_ming.mak PERL=c:/strawberry/perl

          No, this does not work when using Cygwin's mingw, due to how
          Make_ming.mak is designed. It uses $(PERL) to build other paths which
          are passed as arguments to the compiler and so on.

          Basically I'm using a Unix-like environment to "cross compile" a
          native Windows binary, so the build process requires valid "Unix"
          paths, but when it calls on the _native_ Windows installation of
          Perl's xsubpp to generate if_perl.c, that one location in the makefile
          requires a native Windows path.

          >> I also had to tweak GvimExt/Make_ming.mak to change CXX from
          >> $(CROSS_COMPILE)g++-3 to $(CROSS_COMPILE)g++, in case anybody
          >> else is having troulble getting GvimExt to compile with a build
          >> environment similar to mine.
          >
          > I think 'CXX=$(CROSS_COMPILE)g++' is the default.

          That may be something I changed in the past and forgot about.

          - Christian

          --
          Happiness, like misery, is usually self-inflicted.
          Christian J. Robinson <heptite@...> http://christianrobinson.name/

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Ken Takata
          Hi Christian, ... Maybe it is Ruby. Make_cyg.mak was changed in 7.3.815. Now, RUBY_API_VER must be specified as same as Make_ming.mak when you use Ruby. The
          Message 4 of 7 , Feb 21, 2013
          • 0 Attachment
            Hi Christian,

            2013/02/21 Thu 7:50:35 UTC+9 Heptite wrote:

            > I used to build using Make_cyg.mak but stopped in recent months
            > because it no longer worked for me when including one of the scripting
            > interpreters. I include Perl, Python and Ruby, but I can't remember
            > which broke. About the same time Make_ming.mak _started_ working for
            > me when it didn't before.

            Maybe it is Ruby. Make_cyg.mak was changed in 7.3.815.
            Now, RUBY_API_VER must be specified as same as Make_ming.mak
            when you use Ruby. The default compiler was also changed from
            'gcc' to 'i686-pc-mingw32-gcc'.

            You might write your command line so that other people can reproduce
            it easily.

            Regards,
            Ken Takata

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Cesar Romani
            ... It builds fine for me. I use MinGW on Windows 7 with gcc 4.6.2, ActiveState perl 5.16 and ruby 1.9.3p385 Regards, -- Cesar -- -- You received this message
            Message 5 of 7 , Feb 21, 2013
            • 0 Attachment
              On 21/02/2013 07:55 a.m., Ken Takata wrote:
              > Hi Christian,
              >
              > 2013/02/21 Thu 7:50:35 UTC+9 Heptite wrote:
              >
              >> I used to build using Make_cyg.mak but stopped in recent months
              >> because it no longer worked for me when including one of the scripting
              >> interpreters. I include Perl, Python and Ruby, but I can't remember
              >> which broke. About the same time Make_ming.mak _started_ working for
              >> me when it didn't before.
              >
              > Maybe it is Ruby. Make_cyg.mak was changed in 7.3.815.
              > Now, RUBY_API_VER must be specified as same as Make_ming.mak
              > when you use Ruby. The default compiler was also changed from
              > 'gcc' to 'i686-pc-mingw32-gcc'.
              >
              > You might write your command line so that other people can reproduce
              > it easily.

              It builds fine for me. I use MinGW on Windows 7 with gcc 4.6.2,
              ActiveState perl 5.16 and ruby 1.9.3p385

              Regards,

              --
              Cesar

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Christian J. Robinson
              ... After reattempting a compile using Make_cyg.mak, I realized that I was remembering wrong. Here is my command line: make -f Make_cyg.mak -j2
              Message 6 of 7 , Feb 21, 2013
              • 0 Attachment
                On Thu, 21 Feb 2013, Ken Takata wrote:

                > Hi Christian,
                >
                > 2013/02/21 Thu 7:50:35 UTC+9 Heptite wrote:
                >
                >> I used to build using Make_cyg.mak but stopped in recent months
                >> because it no longer worked for me when including one of the
                >> scripting interpreters. I include Perl, Python and Ruby, but I
                >> can't remember which broke. About the same time Make_ming.mak
                >> _started_ working for me when it didn't before.
                >
                > Maybe it is Ruby. Make_cyg.mak was changed in 7.3.815. Now,
                > RUBY_API_VER must be specified as same as Make_ming.mak when you use
                > Ruby. The default compiler was also changed from 'gcc' to
                > 'i686-pc-mingw32-gcc'.
                >
                > You might write your command line so that other people can reproduce
                > it easily.

                After reattempting a compile using Make_cyg.mak, I realized that I was
                remembering wrong. Here is my command line:

                make -f Make_cyg.mak -j2 PERL=/cygdrive/c/strawberry/perl \
                RUBY=/cygdrive/c/Ruby193 RUBY_PLATFORM=i386-mingw32 POSTSCRIPT=yes \
                DYNAMIC_PERL=yes PYTHON=/cygdrive/c/Python27 OLE=yes XPM=xpm \
                FEATURES=BIG

                And here is the linking attempt and the fatal error that occurs:

                i686-pc-mingw32-gcc -O3 -fomit-frame-pointer -freg-struct-return
                -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG
                -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DFEAT_PERL -DDYNAMIC_PERL
                -DDYNAMIC_PERL_DLL=\"perl512.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON
                -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY
                -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191.dll\" -DDYNAMIC_RUBY_VER=191
                -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME
                -DDYNAMIC_IME -DMSWINPS -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG
                -DFEAT_XPM_W32 -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_OLE -march=i386
                -Iproto -I/cygdrive/c/strawberry/perl/lib/CORE
                -I/cygdrive/c/Ruby193/lib/ruby/1.9.1/i386-mingw32
                -I/cygdrive/c/Ruby193/include/ruby-1.9.1
                -I/cygdrive/c/Ruby193/include/ruby-1.9.1/i386-mingw32 -s -mno-cygwin
                -Ixpm/include -o gvim.exe gobj/blowfish.o gobj/buffer.o
                gobj/charset.o gobj/diff.o gobj/digraph.o gobj/edit.o gobj/eval.o
                gobj/ex_cmds.o gobj/ex_cmds2.o gobj/ex_docmd.o gobj/ex_eval.o
                gobj/ex_getln.o gobj/fileio.o gobj/fold.o gobj/getchar.o
                gobj/hardcopy.o gobj/hashtab.o gobj/main.o gobj/mark.o
                gobj/memfile.o gobj/memline.o gobj/menu.o gobj/message.o
                gobj/misc1.o gobj/misc2.o gobj/move.o gobj/mbyte.o gobj/normal.o
                gobj/ops.o gobj/option.o gobj/os_win32.o gobj/os_mswin.o
                gobj/pathdef.o gobj/popupmnu.o gobj/quickfix.o gobj/regexp.o
                gobj/screen.o gobj/search.o gobj/sha256.o gobj/spell.o
                gobj/syntax.o gobj/tag.o gobj/term.o gobj/ui.o gobj/undo.o
                gobj/version.o gobj/vimrc.o gobj/window.o gobj/if_perl.o
                gobj/if_python.o gobj/if_ruby.o gobj/if_cscope.o gobj/netbeans.o
                gobj/xpm_w32.o gobj/gui.o gobj/gui_w32.o gobj/gui_beval.o
                gobj/os_w32exe.o gobj/if_ole.o -L/lib/w32api -L/usr/lib/mingw
                -L/usr/lib/w32api -I/usr/include/mingw -I/usr/include/w32api -luuid
                -lole32 -lwsock32 -Lxpm/lib -Lxpm/x86/lib -lXpm -L/lib/w32api
                -mwindows -lcomctl32 -lversion -loleaut32 -lstdc++
                gobj/eval.o:eval.c:(.text+0x38d4): undefined reference to `_pow'
                collect2: ld returned 1 exit status
                Make_cyg.mak:575: recipe for target `gvim.exe' failed
                make: *** [gvim.exe] Error 1


                So, for now, I'll stick to Make_ming.mak now that I have a workaround
                in place for the path issue I outlined before.

                - Christian

                --
                Nobody believes the official spokesman...
                but everybody trusts an unidentified source. -- Ron Nesen
                Christian J. Robinson <heptite@...> http://christianrobinson.name/

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Ken Takata
                Hi Christian, ... I couldn t compile with this command. Versions of interpreters should be specified like the following: $ make -f Make_cyg.mak -j2
                Message 7 of 7 , Feb 22, 2013
                • 0 Attachment
                  Hi Christian,

                  2013/02/22 Fri 6:21:09 UTC+9 Heptite wrote:

                  > make -f Make_cyg.mak -j2 PERL=/cygdrive/c/strawberry/perl \
                  > RUBY=/cygdrive/c/Ruby193 RUBY_PLATFORM=i386-mingw32 POSTSCRIPT=yes \
                  > DYNAMIC_PERL=yes PYTHON=/cygdrive/c/Python27 OLE=yes XPM=xpm \
                  > FEATURES=BIG

                  I couldn't compile with this command.
                  Versions of interpreters should be specified like the following:

                  $ make -f Make_cyg.mak -j2 PERL=/cygdrive/c/strawberry/perl \
                  RUBY=/cygdrive/c/Ruby193 POSTSCRIPT=yes DYNAMIC_PERL=yes \
                  PYTHON=/cygdrive/c/Python27 OLE=yes XPM=xpm FEATURES=BIG \
                  RUBY_VER=19 RUBY_VER_LONG=1.9.1 PYTHON_VER=27 PERL_VER=516

                  But I still got the following error:

                  /usr/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/bin/ld: cannot find -lXpm
                  collect2: ld returned 1 exit status
                  Make_cyg.mak:575: recipe for target `gvim.exe' failed
                  make: *** [gvim.exe] Error 1

                  After I removed 'XPM=xpm' from the command line, I could build gvim.exe.
                  (I didn't notice that Make_cyg.mak could not build with the bundled XPM library.)


                  > gobj/eval.o:eval.c:(.text+0x38d4): undefined reference to `_pow'

                  Oh, this error comes again!?
                  I have no idea with this error.

                  Regards,
                  Ken Takata

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                Your message has been successfully submitted and would be delivered to recipients shortly.