With Matts talking about CDB_File, I took a look at what it was. It seems to me that it is a standalone XS module, so i took it as the next subject for my trials on compiling XS modules on PXPerl+MinGW. I don't even have an idea what the module is for... but it might prove useful, eventually.
I've had to tweak my environment a little, — well OK, a lot. This is why I despise working with C so much, but I'm planning on struggling my way through it at least once. The closest I finally got, was being left with 2 missing symbols: Perl_report_uninit, and fsync.
Well it appears I'm not the only one with that problem. But other than that, Google doesn't really show me much.
The first problem is fsync(). I find it strange that CDB_File even tries to use fsync(), as Config.pm clearly indicates that $Config{d_fsync} is undefined, meaning, it's unavailable.
Some further poking around, and I found that Python maps fsync() to _commit. Judging by fsync's manpage and the info on _commit, it appears to me that these functions even have the same parameters and the same outcome — I have no idea why they even have a different name. So, why doesn't Perl map fsync to _commit, too?
I'm still left with the Perl_report_uninit problem. Why that one isn't found, I don't know, as it clearly is Perl's problem. A grep shows this symbol is used in two header files, embed.h and proto.h, but it isn't actually defined anywhere. According to other copies I found on Internet, it should have been defined in embed.h, too, but apparently it isn't. Why not, I have no idea.
it clearly is Perl's problem
Naughty Matt. It's actually CDB_File's problem, because it's using a function that's not documented as part of Perl's API, and so isn't exported. Except, sadly, it seems you can't enforce that anywhere except Windows.
I'm not convinced that use.perl is the best place for the discussions
diagnosing bug reports. I think that you should use perlbug (or
mail perl5-porters direct) to suggest using _commit, as the right
people who understand Win32 stuff hang out there. I'm not sure where the best
place is to discuss nailing down the linking issue.
Re:report_uninit
Dom2 on 2006-02-24T11:12:37
This is one of the interesting features between Windows (COFF) vs Linux (ELF). COFF treats each shared library as private by default, whereas ELF is one big global namespace.I can't remember how MacOSX deals with this, but I recall that it's different yet again...
I strongly recommend reading Linkers & Loaders for understanding all this, although as you can tell, it's been a while since I've read my copy...
-Dom
Re:report_uninit
Matts on 2006-02-24T17:35:35
I'm just the maintainer - I promise I've been a good boy:-)
I'd be happy to apply any patches though.Re:report_uninit
bart on 2006-02-24T21:14:46
When I get through the other problem, I'll test if it works (er, passes tests) with _commit() replacing fsync(). I'll let you know then. At a first look, I wouldn't see why not.Re:report_uninit
bart on 2006-02-25T01:41:34
The reason I'm not taking this to P5P is, frankly, that P5P scares me. I'm new at XS, I am actually just stumbling in the dark. So I'm hoping that if I make any blatant mistakes, maybe some friendly soul might correct me before I waste other people's valuable time. (If you smell just a hint of sarcasm, you'd be right.)
For P5P, you're expected to fully know what you're doing, preferably provide patches. I'm not a Perl Porter, I barely know how to work with these C tools, nor do I really like to do this kind of trenchwork.
I might poke some knowledgable people about how well my ideas fly, first, and perhaps they can take it to P5P.
Re:report_uninit
chromatic on 2006-03-26T21:35:56
For P5P, you're expected to fully know what you're doing...I've never felt that way (and I still don't know what I'm doing). I just try to show a reasonable effort and that seems to work fine.
