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