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] |
I can't find any trace of "seed" in perlapi either. For a core module, that's bad, IMO
It may be a deficiency in perlapi. 'Perl_seed' is in embed.fnc (as the entry 'Ap|U32|seed' .... something I learnt from the response to a follow-up post I sent to the xs mailing list) so it really ought to be available. The fact that it's not available in PXPerl really does sound like a PXPerl bug. There's certainly no problem there with ActiveState perl (or any of the other Win32 perls that I have).
Cheers,
Rob
| [reply] |