in reply to Re^3: Weird problems building Scalar-List-Utils-1.18 on Win32+MinGW
in thread Weird problems building Scalar-List-Utils-1.18 on Win32+MinGW

OK, I found back what other module I was having similar problems to: CDB_File. In that case, the errors for PXPerl and for ActivePerl were identical. That's why I have confidence in PXPerl, why I don't think it's that bad.

One symbol, "fsync" wasn't found, because it doesn't exist on Win32. It should be made equivalent to "_commit" using a macro. But the other symbol is an identical problem as I see here for 'Perl_seed': 

D:/PXPerl/.cpan/build/CDB_File-0.94/CDB_File.xs:462: undefined referen
+ce to `Perl_report_uninit'

[download]

This is the output I get from the latest version of ActivePerl, 5.8.8 build 817, downloaded this morning: 

cpan> test CDB_File
...
cp bun-x.pl blib\lib\bun-x.pl
cp CDB_File.pm blib\lib\CDB_File.pm
        C:\Perl\bin\perl.exe C:\Perl\lib\ExtUtils\xsubpp  -typemap C:\
+Perl\lib\ExtUtils\typemap -typemap typemap  CDB_File.xs > CDB_File.xs
+c && C:\Perl\bin\perl.exe -MExtUtils::Command -e mv CDB_File.xsc CDB_
+File.c
        gcc -c    -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_F
+CRYPT -DNO_HASH_SEED -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPE
+RL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DHASATTRIBUTE -fn
+o-strict-aliasing -O2    -DVERSION=\"0.94\"  -DXS_VERSION=\"0.94\"  "
+-IC:\Perl\lib\CORE"   CDB_File.c
In file included from CDB_File.xs:39:
ppport.h:227:1: warning: "PERL_UNUSED_DECL" redefined
In file included from CDB_File.xs:37:
C:/Perl/lib/CORE/perl.h:165:1: warning: this is the location of the pr
+evious definition
Running Mkbootstrap for CDB_File ()
        C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod 644 CDB_File
+.bs
        C:\Perl\bin\perl.exe -MExtUtils::Mksymlists  -e "Mksymlists('N
+AME'=>\"CDB_File\", 'DLBASE' => 'CDB_File', 'DL_FUNCS' => {  }, 'FUNC
+LIST' => [], 'IMPORTS' => {  }, 'DL_VARS' => []);"
Set up gcc environment - 3.2.3 (mingw special 20030504-1)
        dlltool --def CDB_File.def --output-exp dll.exp
        gcc -o blib\arch\auto\CDB_File\CDB_File.dll -Wl,--base-file -W
+l,dll.base -mdll CDB_File.o -Wl,--image-base,0x52d0000  C:\Perl\lib\C
+ORE\perl58.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -lad
+vapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
+-lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt dll.exp
CDB_File.o(.text+0x187f):CDB_File.c: undefined reference to `Perl_repo
+rt_uninit'

CDB_File.o(.text+0x1b08):CDB_File.c: undefined reference to `Perl_repo
+rt_uninit'

CDB_File.o(.text+0x2076):CDB_File.c: undefined reference to `Perl_repo
+rt_uninit'

CDB_File.o(.text+0x271c):CDB_File.c: undefined reference to `Perl_repo
+rt_uninit'

CDB_File.o(.text+0x3632):CDB_File.c: undefined reference to `fsync'
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
+ '0x1'
Stop.
  nmake  -- NOT OK
Running make test
  Can't test without successful make

[download]

Feel free to dig your nails into that one.

Replies are listed 'Best First'.
Re^5: Weird problems building Scalar-List-Utils-1.18 on Win32+MinGW
by syphilis (Archbishop) on Jun 21, 2006 at 01:39 UTC
    OK, I found back what other module I was having similar problems to: CDB_File

    I don't think this is in any way a similar problem to the one with S::L::U-1.18.
    Firstly, the errors with CDB_File arise during the 'make' phase. (The S::L::U-1.18 error with AS perl occurs at the 'perl Makefile.PL' stage - a result of the Makefile.PL wanting to 'use inc::Module::Install').
    Secondly this error with CDB_File seems to affect every build of Win32 perl. (I don't get the S::L::U-1.18 error with any of the Win32 5.8.8 perls that I have built myself.)

    I don't know the solution to the CDB_File error - I get the same error with perl 5.8.4 on Win32, so it has been there for quite some time - probably since 5.8.0. On linux (perl 5.8.8), I find no problem in building CDB_File-0.94, so there's obviously something Win32-specific happening wrt 'Perl_report_uninit'.

    Cheers,
    Rob
[reply]
      I don't know the solution to the CDB_File error

      Well, I now know part of the solution. I asked about 'Perl_report_uninit' on the xs mailing list and Jan Dubois replied as follows:

      "Perl_report_uninit() is not a public Perl API, so extensions are not allowed to call it. On Linux this cannot be enforced as all internal symbols are being exported anyways, but on Windows (and AIX) you can only call APIs that are marked as 'public' in the embed.fnc file in the core Perl distribution."

      However it seems that calling Perl_report_init() does the same as 'warn("Use of uninitialized value in subroutine entry");' - so I replaced the 4 instances of Perl_report_init() in CDB_File.xs with precisely that. On linux, with those changes in place, the module still builds and tests fine. However, on Win32, although it now builds fine, there are still some failures in the test suite - probably because my handling of 'fsync'. For that, all I did was insert '#define fsync _commit' near the beginning of CDB_File.xs, but apparently that is not good enough.

      Cheers,
      Rob
[reply]
        "Perl_report_uninit() is not a public Perl API, so extensions are not allowed to call it. On Linux this cannot be enforced as all internal symbols are being exported anyways, but on Windows (and AIX) you can only call APIs that are marked as 'public' in the embed.fnc file in the core Perl distribution."
        That is what I suspected what was going on, without knowing for sure or being able to stick any labels on it. You see: I couldn't find a trace of it in perlapi, so I suspected it wasn't official, but then I examined the perl source code for the difference between this symbol and stuff that is official, I just couldn't find any. Well, I seem to have been looking in the wrong place.

        Thanks for filling in the blanks.

        Quote from the parent, by the same author:

        I don't think this is in any way a similar problem to the one with S::L::U-1.18.
        When I said that, I wasn't talking about the behaviour on ActivePerl, but about the symbol Perl_seed which likely is similar.

        I can't find any trace of "seed" in perlapi either. For a core module, that's bad, IMO.

        vkon posted the cookbook recipe for how to handle this, so I think that probably about wraps it up for me.

[reply]
[d/l]

In Section Seekers of Perl Wisdom