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
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.