Bill Moseley <[EMAIL PROTECTED]> writes:
>I have a module that is a xs interface to the Aspell/Pspell library. The
>library is written in c++. The module is Text::Pspell on CPAN.
Whether and how constructors get called for static objects
defined in loadables is rather platform dependent.
linux and Solaris both use (I believe) hooks in ELF object format
to make this happen.
BSD may still be using a traditional "a.out" object format which does
not have the hooks (e.g. SunOS also used to fail this sort of thing.)
>
>It works perfectly on my SuSE/perl 5.6.0 machine.
>
>It works perfectly on Solaris 2.6 perl 5.005_03
>
>On my Debian woody with perl 5.6.1 it gives a sig abort if run with
>PERL_DL_NONLAZY=1 but works fine when PERL_DL_NONLAZY=0 (red herring is my
>guess).
>
>On FreeBSD 4.5 with 5.005_03 it always aborts (regardless of PERL_DL_NONLAZY).
>
>If I copy the .xs code into a main {} block and build a stand-alone C
>program it works fine everyplace.
Static linking the extension into perl should also work.
>
>My efforts with gdb have not been very successful.
gdb on loadables is itself a bit messy.
>
>What seems to be happening is that the aspell c++ code attempts to open
>configuration files, and when a file is not found it aborts. These config
>files are *optional* and don't exist on any of my platforms. On the debian
>system, where it only aborts with PERL_DL_NONLAZY=1 (which is set with
>"make test"), if I touch all the config files then make test then runs
>without problem.
>
>The aspell c++ code throws an exception when a config file doesn't exist.
>But the code that reads the config file is wrapped in a try / catch block,
>and the catch block just ignores the error (empty block).
exceptions have been subject to radical re-design in gcc - if your free bsd
machine has as old a gcc as it has a a perl chances are exceptions just
don't work right at all.
>
>I edited the aspell source code to print a message as the last line of the
>exception constructor, and also in the catch block. The idea is the
>exception is thrown, the constructor is called, and then the catch block
>should be executed. (Note: I'm not a c++ programmer..)
>
>So with PERL_DL_NONLAZY=0 I see the message from the constructor, and then
>from the catch block. But with PERL_DL_NONLAZY=1 I see the constructor
>message and then the program aborts without displaying the line from the
>catch block.
>
>I don't know c++. From what I understand what happens between the
>exception constructor and the catch block is that any nested objects are
>destroyed. So perhaps there's another exception or abort() called in one
>of those.
>
>But to me it seems more like a problem with Perl since all I'm changing is
>PERL_DL_NONLAZY.
I think all that does is pass itself on to system's dlopen()
>I have not been able to see anything with gdb single
>stepping through the code after the exception is called, but that could be
>my poor debugging skills.
Or gdb not understanding exceptions well either.
>
>I don't think it's really an issue with what PERL_DL_NONLAZY does, as it's
>hard to imagine why perl's behavior with dlopen() would have anything to do
>with what's happening in the c++ shared library. But that's just a guess.
>
>Anyway, it's obvious that I'm stuck. Any suggestions?
>
>Thanks,
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
