Front page | perl.perl5.porters |
Postings from August 2001
[ID 20010830.001] 5.6.1 win32 dmake building problems
Thread Next
From:
Walter Briscoe
Date:
August 30, 2001 01:23
Subject:
[ID 20010830.001] 5.6.1 win32 dmake building problems
Message ID:
TeF5wLARffj7EwfC@ponle.demon.co.uk
This is a bug report for perl from w.briscoe@ponle.demon.co.uk,
generated with the help of perlbug 1.33 running under perl v5.6.1.
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)
Thread Next
-
[ID 20010830.001] 5.6.1 win32 dmake building problems
by Walter Briscoe