develooper Front page | perl.perl5.porters | Postings from May 2012

[perl #7602] 5.6.1 win32 dmake building problems

Thread Previous
From:
Brian Fraser via RT
Date:
May 7, 2012 13:06
Subject:
[perl #7602] 5.6.1 win32 dmake building problems
Message ID:
rt-3.6.HEAD-4610-1336226732-253.7602-15-0@perl.org
On Wed Aug 29 18:23:05 2001, wbriscoe@ponle.demon.co.uk wrote:
> I built perl in Windows 2000 as a first step to building it in
> a win9x system. I had some difficulties which I report. I failed to
> build in a Windows Millennium Edition system on the same machine. I am
> sorry this is such a long report. I rejected splitting it into several
> reports as the total volume would have been greater in that case.
> 
> I unpacked
>     http://www.perl.com/CPAN-local/ports/nt/Standard/x86/perl-
>    5.6.1.tar.gz
> and took instructions from perl-5.6.1\README.win32.
> 
> I got the port of dmake from
>     http://www.cpan.org/authors/id/GSAR/dmake-4.1pl1-win32.zip
> I found that http://dmake.wticorp.com/ has gone silent.
> C:\>ping dmake.wticorp.com
> 
> Pinging dmake.wticorp.com [209.185.218.5] with 32 bytes of data:
> 
> Request timed out.
> Request timed out.
> Request timed out.
> Request timed out.
> 
> C:\>
> 
> I had problems with the Visual C++ port of dmake. I solved what I had
>    to
> and will liaise with Gurusamy and anyone else interested in them.
> 
> I used Gurusamy's dmake build to reduce variability until I hit
> problems with dmake itself.
> 
> I changed dmake's startup\config.mk to reflect my environment as best
>    as
> possible by setting
> !    OSRELEASE     *:= microsft
> !    OSENVIRONMENT *:= vcpp40
> rather than
> !    OSRELEASE     *:= borland
> !    OSENVIRONMENT *:= bcc50
> 
> I set those data as they were the nearest available in the original
> version (Dennis Vadura's) of dmake and corresponded closest to my
> situation in which I used Visual C++ 6.0 with no service packs.
> 
> It later emerged that this was a mistake! I report the solution here
> and the problem later where it occurred. There is a bug in dmake which
>    I
> worked round with the following patch:
> 
> *** startup/win32/microsft/0macros.mkWed Dec  9 00:48:30 1998
> --- startup/win32/microsft/macros.mkFri Aug 24 21:40:38 2001
> ***************
> *** 32,38 ****
>   PC   *:= ???# pascal compiler
>   RC   *:= ???# ratfor compiler
>   FC   *:= ???# fortran compiler
> -
> -
> - # Directory cache configuration.
> - .DIRCACHE *:= no
> --- 32,34 ----
> 
> dmake does different things dependent on the setting of DIRCACHE.
> makefile.mk goes into an infinite loop unless it is specified. I
>    suspect
> this is a bug in dmake masking a bug in makefile.mk. I have not proved
> it as my immediate need was to find a path to a build and simplifying
> the problem to prove its cause and find a solution seems unreasonably
> difficult to do now.
> 
> I configured win32/makefile.mk as shown in the attached diff:
> 
> *** perl-5.6.1/win32/0makefile.mk       Mon Apr  9 04:13:50 2001
> --- perl-5.6.1/win32/makefile.mk        Fri Aug 24 18:43:34 2001
> ***************
> *** 32,42 ****
>   # Visual C++ > 2.x and < 5.x SP3
>   #CCTYPE               *= MSVC_PRE_50SP3
>   # Visual C++ >= 5.x SP3
> ! #CCTYPE               *= MSVC60
>   # Borland 5.02 or later
>   #CCTYPE               *= BORLAND
>   # mingw32+gcc-2.95.2 or better
> ! CCTYPE                *= GCC
> 
>   #
>   # uncomment this if your Borland compiler is older than v5.4.
> --- 32,42 ----
>   # Visual C++ > 2.x and < 5.x SP3
>   #CCTYPE               *= MSVC_PRE_50SP3
>   # Visual C++ >= 5.x SP3
> ! CCTYPE                *= MSVC60
>   # Borland 5.02 or later
>   #CCTYPE               *= BORLAND
>   # mingw32+gcc-2.95.2 or better
> ! #CCTYPE               *= GCC
> 
>   #
>   # uncomment this if your Borland compiler is older than v5.4.
> ***************
> *** 56,63 ****
>   # the path name should not be quoted.
>   #
>   #CCHOME               *= F:\Borland\BC5
> ! #CCHOME               *= $(MSVCDIR)
> ! CCHOME                *= c:\gcc-2.95.2-msvcrt
> 
>   CCINCDIR      *= $(CCHOME)\include
>   CCLIBDIR      *= $(CCHOME)\lib
> --- 56,63 ----
>   # the path name should not be quoted.
>   #
>   #CCHOME               *= F:\Borland\BC5
> ! CCHOME                *= $(MSVCDIR)
> ! #CCHOME               *= c:\gcc-2.95.2-msvcrt
> 
>   CCINCDIR      *= $(CCHOME)\include
>   CCLIBDIR      *= $(CCHOME)\lib
> ***************
> *** 635,641 ****
> 
>   XCOPY         = xcopy /f /r /i /d
>   RCOPY         = xcopy /f /r /i /e /d
> ! NOOP          = @echo
> 
>   #
>   # filenames given to xsubpp must have forward slashes (since it puts
> --- 635,641 ----
> 
>   XCOPY         = xcopy /f /r /i /d
>   RCOPY         = xcopy /f /r /i /e /d
> ! NOOP          = rem
> 
>   #
>   # filenames given to xsubpp must have forward slashes (since it puts
> 
> Of these, the change of NOOP from @echo to rem is notable. I found
> frightening "ECHO is on." in NTx and "ECHO is on" in 9X at various
> points. Why was it necessary to overrule the NOOP built in to dmake?
> 
> I ran vcvars32.bat to set the environment for Visual C++ 6.0, and ran
> dmake in perl-5.6.1/win32. It went into an infinite loop of fruitless
> attempts to make a valid config.pm. I found the behaviour was the
>    result
> of a diff by config_h.PL which is always going to fail as the config.h
> produced by config_h.sh contains $cf_time and $cf_by which will never
> match. Is an intelligent diff intended? The least expensive workaround
> was to change the dmake configuration as already detailed.
> 
> That looks like a bug in dmake to me! There was a similar problem in
> ext/B. I succeeded! I ran dmake test and got the following failures
> which I have not attempted to diagnose:
> 
> op/magic............The system cannot find the file
>    C:\WFB\bin\ansi.com.
> The system cannot find the file C:\WFB\bin\ansi.com.
> FAILED tests 29-30
>         Failed 2/35 tests, 94.29% okay (-2 skipped tests: 31 okay,
>    88.57%)
> I will cooperate in diagnosing this if somebody takes it on.
> 
> I did dmake install. I got a whole pile of diagnostics from which I
>    extract:
> ..\perl.exe -I..\lib ..\installhtml --podroot=.. --htmldir=./html \
>             --podpath=pod:lib:ext:utils
>    --htmlroot="file://c|\perl\5.6.1\html"\
>             --libpod=perlfunc:perlguts:perlvar:perlrun:perlop
>    --recurse
> ..\installhtml: ../pod/perl.pod: cannot resolve L<xsubpp> in paragraph
>    42. at ..\lib/Pod/Html.pm line 1562.
> ..\installhtml: ../pod/perl5004delta.pod: cannot resolve L<h2xs> in
>    paragraph 215. at ..\lib/Pod/Html.pm line 1562.
> Again, I have not attempted diagnosis until I get feedback.
> 
> README.win32 could probably usefully changed to refer to the current
> build of perl as shown in the attached diff:
> 
> *** perl-5.6.1/0readme.win32    Mon Apr  9 04:13:50 2001
> --- perl-5.6.1/readme.win32     Sat Aug 25 10:19:28 2001
> ***************
> *** 269,275 ****
>   C<$INST_TOP\$VERSION\bin> and C<$INST_TOP\$VERSION\bin\$ARCHNAME>.
>   For example:
> 
> !     set PATH c:\perl\5.6.0\bin;c:\perl\5.6.0\bin\MSWin32-x86;%PATH%
> 
>   If you opt to comment out INST_VER and INST_ARCH in the makefiles,
>    the
>   installation structure is much simpler.  In that case, it will be
> --- 269,275 ----
>   C<$INST_TOP\$VERSION\bin> and C<$INST_TOP\$VERSION\bin\$ARCHNAME>.
>   For example:
> 
> !     set PATH c:\perl\5.6.1\bin;c:\perl\5.6.1\bin\MSWin32-x86;%PATH%
> 
>   If you opt to comment out INST_VER and INST_ARCH in the makefiles,
>    the
>   installation structure is much simpler.  In that case, it will be
> 
> Building in a win9x environment is MUCH harder. The first problem is
> that the syntax of the del and rmdir commands differ. I suggest a ZAP
> macro to evaluate to call zap.bat with contents such as:
> 
> :: zap.bat
> ::
> :: A file to erase its arguments portable to Windows NT and 9X systems
> ::
> :: When       Who       What
> :: 2001-08-20 W.Briscoe Original
> @echo off
> :nextarg
> if %1.==. goto:eof
> if "%OS%" == "Windows_NT" goto ntsystem
> >nul deltree /y %1
> shift
> goto nextarg
> :ntsystem
> if exist %1 del /q /f %1
> if exist %1/ rmdir /q /s %1 || rmdir /s %1
> shift
> goto nextarg
> :eof
> 
> There may be a problem in that it always forces and may not give a
> return code. Lack of a return code is also a win9x problem with
>    inbuilt
> commands. There may also be a problem in that dmake, as configured
> above, filters most of the environment and sets %OS% to win32 in all
> cases. I don't have a clean solution.
> 
> I started to build in win9x (Millennium Edition). dmake failed:
> call zap.bat config.h
> copy config_H.vc config.h > nul
> DMAKE.EXE:  Error -- `.\makefile.mk' not found, and can't be made
> 
> C:\WFB\perl-5.6.1\win32>
> 
> I switched from Gurusamy's to my own port of dmake and skipped that
> trouble. I have not attempted to analyse the problem. As always, I am
> available.
> 
> I hit lots of diagnostics of which the following is typical:
> C:\WFB\perl-5.6.1\win32>        cd ..\ext\Socket
> 
> C:\WFB\perl-5.6.1\ext\Socket>   C:\WFB\BIN\DMAKE.EXE -S
> DMAKE.EXE:  Error -- Ambiguous inference chains for target
>    'Socket.obj'
> DMAKE.EXE:   1. Socket.obj(%.obj) --> Socket.xs(%.xs)
> DMAKE.EXE:   2. Socket.obj(%.obj) --> Socket.c(%.c)
> DMAKE.EXE:  Error -- resolve ambiguity before proceeding.
> I am disturbed that this did not stop the build.
> The following at the end of socket.c suggests the problem is in the
> creation of ..\ext\Socket
> "Please specify prototyping behavior for Socket.xs (see perlxs
>    manual)"
> 
> The file ..\ext\Socket\&1 contains:
> Usage: xsubpp [-v] [-C++] [-except] [-prototypes] [-noversioncheck] [-
>    nolinenumbers] [-nooptimize] [-noinout] [-noargtypes] [-s pattern]
>    [-typemap typemap]... file.xs
> 
> I crawled back and found that makemaker had made the attached
> differences of which the following seem significant:
> ! XSPROTOARG = -noprototypes
> ! XSPROTOARG =
> 
> *** 288,298 ****
>   # --- MakeMaker xs_c section:
> 
>   .xs.c:
> ! $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) $(XSPROTOARG)
>    $(XSUBPPARGS) $*.xs > $*.xsc && $(MV) $*.xsc $*.c
> !
> 
>   # --- MakeMaker xs_o section:
> 
> 
>   # --- MakeMaker top_targets section:
> 
> --- 288,304 ----
>   # --- MakeMaker xs_c section:
> 
>   .xs.c:
> ! $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) \
> !     $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.c
> !
> 
>   # --- MakeMaker xs_o section:
> 
> + .xs$(OBJ_EXT):
> + $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) \
> +     $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.c
> + $(CCCMD) $(CCCDLFLAGS) -I$(PERL_INC) $(DEFINE) $*.c
> +
> 
>   # --- MakeMaker top_targets section:
> 
> *** ../4perl-5.6.1/ext/socket/MakefileSat Aug 25 08:22:08 2001
> --- ext/socket/MakefileSat Aug 25 12:00:00 2001
> ***************
> *** 74,81 ****
>   PERLMAINCC = $(CC)
>   PERL_SRC = ..\..
>   PERL_INC = ..\..\lib\CORE
> ! PERL = ..\..\miniperl
> ! FULLPERL = ..\..\perl
> 
>   VERSION_MACRO = VERSION
>   DEFINE_VERSION = -D$(VERSION_MACRO)=\"$(VERSION)\"
> --- 74,81 ----
>   PERLMAINCC = $(CC)
>   PERL_SRC = ..\..
>   PERL_INC = ..\..\lib\CORE
> ! PERL = C:\WFB\PERL-5~1.1\MINIPERL.EXE
> ! FULLPERL = C:\WFB\PERL-5~1.1\perl.EXE
> 
>   VERSION_MACRO = VERSION
>   DEFINE_VERSION = -D$(VERSION_MACRO)=\"$(VERSION)\"
> ***************
> *** 164,170 ****
> 
>   XSUBPPDIR = ..\..\lib\ExtUtils
>   XSUBPP = $(XSUBPPDIR)/xsubpp
> ! XSPROTOARG = -noprototypes
>   XSUBPPDEPS = $(XSUBPPDIR)\typemap $(XSUBPP)
>   XSUBPPARGS = -typemap $(XSUBPPDIR)\typemap
> 
> --- 164,170 ----
> 
>   XSUBPPDIR = ..\..\lib\ExtUtils
>   XSUBPP = $(XSUBPPDIR)/xsubpp
> ! XSPROTOARG =
>   XSUBPPDEPS = $(XSUBPPDIR)\typemap $(XSUBPP)
>   XSUBPPARGS = -typemap $(XSUBPPDIR)\typemap
> 
> ***************
> *** 288,298 ****
>   # --- MakeMaker xs_c section:
> 
>   .xs.c:
> ! $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) $(XSPROTOARG)
>    $(XSUBPPARGS) $*.xs > $*.xsc && $(MV) $*.xsc $*.c
> !
> 
>   # --- MakeMaker xs_o section:
> 
> 
>   # --- MakeMaker top_targets section:
> 
> --- 288,304 ----
>   # --- MakeMaker xs_c section:
> 
>   .xs.c:
> ! $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) \
> !     $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.c
> !
> 
>   # --- MakeMaker xs_o section:
> 
> + .xs$(OBJ_EXT):
> + $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) \
> +     $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.c
> + $(CCCMD) $(CCCDLFLAGS) -I$(PERL_INC) $(DEFINE) $*.c
> +
> 
>   # --- MakeMaker top_targets section:
> 
> ***************
> *** 725,731 ****
> 
>   # --- MakeMaker makeaperl section ---
>   MAP_TARGET    = perl
> ! FULLPERL      = ..\..\perl
> 
>   $(MAP_TARGET) :: static $(MAKE_APERL_FILE)
>   $(MAKE) -f $(MAKE_APERL_FILE) $@
> --- 731,737 ----
> 
>   # --- MakeMaker makeaperl section ---
>   MAP_TARGET    = perl
> ! FULLPERL      = C:\WFB\PERL-5~1.1\perl.EXE
> 
>   $(MAP_TARGET) :: static $(MAKE_APERL_FILE)
>   $(MAKE) -f $(MAKE_APERL_FILE) $@
> 
> I don't know how to diagnose Makemaker bahaviour.
> 
> win32/makefile.mk uses win32/genmk95.pl to produce makefile.95 for use
> with 9x systems. It simplifies && and || to use the limited
>    capabilities
> of command.com. It uses dmake's "group recipe" capability. It does not
> say that this is also needed to allow communication between cd and
> adjacent commands.
> 
> I hit this when looking at the failure to run the clean rule in
> genmk95.pl. It seems to hit a bug in dmake. The recipe element
>         -@erase miniperlmain$(o)
> causes `erase miniperlmain.obj` to be run silently and the response
> ignored. However, in a group, `-@erase miniperlmain.obj' is run and
> the command fails due to the noise at the start. It took me quite some
> time to find the following patch. I have only tested it to fix the
> particular problem.
> 
> *** dmake.1/0parse.cTue Jul 15 17:02:26 1997
> --- dmake.1/parse.cWed Aug 29 17:06:30 2001
> ***************
> *** 72,78 ****
> 
>                  if( Group ) {
>                     if( *p != ']' ) {
> !                      Add_recipe_to_list( Buffer, TRUE, TRUE );
>                        rule = TRUE;
>                     }
>                     else
> --- 72,79 ----
> 
>                  if( Group ) {
>                     if( *p != ']' ) {
> !                      /* TRUE -> FALSE to strip prefixes in group */
> !                      Add_recipe_to_list( Buffer, TRUE, FALSE );
>                        rule = TRUE;
>                     }
>                     else
> 
> I hope my amusement during vacation helps. I have dmake from it and
>    that
> looks like a VERY useful tool. I continue to believe that perl is NOT
> buildable on w9x systems.  I am impressed that people try to make it
>    so.
> (I do have the activestate port if I want it.)
> I would be pleased to assist in making perl buildable in w9x.
> Currently, I am clouded by the difference in behaviour of makemaker.
> 
> ---
> Flags:
>     category=install
>     severity=high
> ---
> Site configuration information for perl v5.6.1:
> 
> Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
>   Platform:
>     osname=MSWin32, osvers=4.0, archname=MSWin32-x86
>     uname=''
>     config_args='undef'
>     hint=recommended, useposix=true, d_sigaction=undef
>     usethreads=undef use5005threads=undef useithreads=undef
>    usemultiplicity=undef
>     useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
>     use64bitint=undef use64bitall=undef uselongdouble=undef
>   Compiler:
>     cc='cl', ccflags ='-O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
>    -DPERL_MSVCRT_READFIX',
>     optimize='-O1 -MD -DNDEBUG',
>     cppflags='-DWIN32'
>     ccversion='', gccversion='', gccosandvers=''
>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>     d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
>     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
>    lseeksize=4
>     alignbytes=8, usemymalloc=n, prototype=define
>   Linker and Libraries:
>     ld='link', ldflags ='-nologo -nodefaultlib -release
>    -libpath:"c:\perl\5.6.1\lib\MSWin32-x86\CORE"   -machine:x86'
>     libpth=c:\gcc-2.95.2-msvcrt\lib
>     libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
>    comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
>    netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib
>    odbc32.lib odbccp32.lib msvcrt.lib
>     perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
>    winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
>    oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib
>    version.lib odbc32.lib odbccp32.lib msvcrt.lib
>     libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib
>   Dynamic Linking:
>     dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
>     cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
>    -libpath:"c:\perl\5.6.1\lib\MSWin32-x86\CORE"   -machine:x86'
> 
> Locally applied patches:
> 
> 
> ---
> @INC for perl v5.6.1:
>     C:/WFB/perl-5.6.1/lib
>     .
> 
> ---
> Environment for perl v5.6.1:
>     HOME=C:\WFB
>     LANG (unset)
>     LANGUAGE (unset)
>     LD_LIBRARY_PATH (unset)
>     LOGDIR (unset)
>    
PATH=C:\PF\MVS\COMMON\MSDEV98\BIN;C:\PF\MVS\VC98\BIN;C:\PF\MVS\COMMON\TOOLS\WIN95;C:\PF\MVS\COMMON\TOOLS;C:\WINME\SYSTEM;C:\PF\MVS\COMMON\TOOLS\WIN95;C:\PF\MVS\COMMON\TOOLS;C:\WINME\SYSTEM;C:\PERL\56269D~1.1\BIN;C:\PERL\56269D~1.1\BIN\MSWIN3~1;C:\PF\DVSTUDIO\SHARED~1\BIN;C:\WINME;C:\WINME\COMMAND;C:\WFB\BIN;C:\PF\ISHIELD\I55PE\PROGRAM;C:\WFB\FTP\FTPCSP~1.EDU\PUB\ELVIS\EXTRACT;C:\CYGWIN\BIN
>     PERL_BADLANG (unset)
>     SHELL (unset)

Thanks for the throughout report! Shame that it has sat abandoned in rt
for so long; Could a Windows porter chime in on whenever this still
applies to recent Perls/dmake?


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=7602

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About