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

[Christian J. Robinson]

On Thu, Feb 7, 2013 at 12:44 PM, Christian J. Robinson
<hep...@gmail.com> 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 <hep...@gmail.com>

[Ken Takata]

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

[Christian J. Robinson]

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 <hep...@gmail.com> http://christianrobinson.name/

[Ken Takata]

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

[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

[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 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

[Ken Takata]

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