From andreas@mrs.ch

Compiled with MingW32 under WinNT4, SP6a

Fork failed completely and I had to remove it from the testscript
directory (the test procedure stoped during the fork failure).

Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
lib/extutils.t 10 1 10.00% 10
pragma/autouse.t 10 1 10.00% 10
pragma/warnings.t 430 1 0.23% 405
28 tests and 141 subtests skipped.
Failed 3/369 test scripts, 99.19% okay. 3/23358 subtests failed, 99.99% okay.
dmake.exe​: Error code 9, while making 'test'

Flags:
    category=install
    severity=none

Site configuration information for perl v5.7.1:

Configured by FehrA at Thu May 31 07:50:01 2001.

Summary of my perl5 (revision 5 version 7 subversion 1) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='gcc', ccflags ='-g -O2 -DWIN32  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX',
    optimize='-g -O2',
    cppflags='-DWIN32'
    ccversion='undef', gccversion='', gccosandvers='undef'
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-g -L"c:\bin\temp\perl\5.7.1\lib\MSWin32-x86-multi-thread\CORE" -L"c:\bin\fsf\gcc-2.95.2-msvcrt\lib"'
    libpth=c:\bin\fsf\gcc-2.95.2-msvcrt\lib
    libs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lwsock32 -lmpr -lwinmm -lversion -lodbc32
    perllibs=undef
    libc=-lmsvcrt, so=dll, useshrplib=yes, libperl=libperl57.a
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -g -L"c:\bin\temp\perl\5.7.1\lib\MSWin32-x86-multi-thread\CORE" -L"c:\bin\fsf\gcc-2.95.2-msvcrt\lib"'

Locally applied patches:
    DEVEL10326


@INC for perl v5.7.1:
    ..\lib
    c:/docs/source/perl
    F:/temp/perl@10328/lib
    .


Environment for perl v5.7.1:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\bin\fsf\gcc-2.95.2-msvcrt\bin;C:\WINNT4.0\system32;C:\WINNT4.0;C:\bin\perl\5.6.1\bin;C:\bin\perl\5.6.1\bin\MSWin32-x86-multi-thread;c:\bin\exe;c:\bin\fsf\dmake
    PERL5LIB=c:/docs/source/perl
    PERL_BADLANG (unset)
    SHELL (unset)

From [Unknown Contact. See original ticket]

I am seeing the fork and warnings fails too with latest and VC++
Others have gone.

The fork fails are PerlIO related ...

From [Unknown Contact. See original ticket]

Win32 fork is broken by Change 10255.
//depot/perlio/perlio.c#92 has a hack to disable the change on Win32
till we have a real solution.

From [Unknown Contact. See original ticket]

pragma/warnings.t 430 1 0.23% 405

That one is caused by EXPECT part of test having (e.g.)

1.23456e-10

but Win32 producing

1.23456e-010

Changed the test in question to use OPTION regex and added 0?.

From [Unknown Contact. See original ticket]

With my copy that is now only fail with Mingw32.
It is due to dll.base and dll.exp being left after clean.

(VC++ does not leave those around as its link scheme is cleaner.)

Not sure what the right fix is yet.

From [Unknown Contact. See original ticket]

NI> Andreas Fehr <andreas@​mrs.ch> writes​:
NI> >Failed Test Stat Wstat Total Fail Failed List of Failed
NI> >-------------------------------------------------------------------------------
NI> >lib/extutils.t 10 1 10.00% 10
NI>
NI> With my copy that is now only fail with Mingw32.
NI> It is due to dll.base and dll.exp being left after clean.
NI>
NI> (VC++ does not leave those around as its link scheme is cleaner.)
NI>
NI> Not sure what the right fix is yet.

?? I never called 'dmake clean', and there is no dll* in the tgz? Does
the makefile call some clean during the make process??

From [Unknown Contact. See original ticket]

lib/extutils.t 10 1 10.00% 10

With my copy that is now only fail with Mingw32.
It is due to dll.base and dll.exp being left after clean.

(VC++ does not leave those around as its link scheme is cleaner.)

Not sure what the right fix is yet.

I doubt that this matter has to do with the lib/extutils.t failure, nor
with Mingw32 (which uses GNU make doesn't it?), but I wrote to let folks
know that the `dmake clean` target does not currently get run via the
miniperl script for ext/ cleanup. A consequence is that the dll's and
other such files get left behind in the ext/... tree after `dmake clean`.
`dmake clean` currently only removes *.obj type intermediate files in the
main perl source directory (and perhaps some sub directories such as
win32/ and x2p/).

I have been working up a patch for it, but it is not yet ready for
posting.

Peter Prymmer

From [Unknown Contact. See original ticket]

The test that is failing is newish one for ExtUtils​::MakeMaker.
That builds a dummy extension and then runs make clean on that.
The test is (correctly) complaining that "make clean" has left
stuff lying about.

The Mingw32 part of the Win32 part of MakerMaker needs attention I think...

@jhi - Status changed from 'open' to 'resolved'

From @jhi

Andreas, I'm marking all your reports on build problems on "MSWin32-x86-multi-thread 4.0", either on pre-5.8.0, or the one in 5.6.1-RC3, as resolved.

Not that I think all of the problems have been resolved (e.g. I think some Win32 variants still suffer from the socketpair.t failures, and some others from the win32/system.t failures), but simply because I think we do not need *all* of these reports :-)

An updated bug report from the 5.8.0 final and/or 5.6.1 from MinGW (or other Win32s) would be nice (assuming there are still failures, that is).

@jhi - Status changed from 'open' to 'resolved'