Bill Moseley <[EMAIL PROTECTED]> writes: >At 10:03 PM 05/20/02 +0100, Nick Ing-Simmons wrote: >>It works on linux/solaris and probably elsewhere with modern C++ >>systems. > >What "it" are you referring to? My module?
Yes. > >>Anything which mixes C++, exceptions and dynamic loading is not >>going to be as portable as perl (which is just ANSI C). > >What's weird is that my two linux systems are very similar. I might expect >it to not work on a different platform, but not on two different linux >systems. > >My SuSE 6.2: > Perl 5.6.0 built from source, gcc version 2.95.3 20010315 (release) > >My Debian Woody is > Perl 5.6.1 debian package, gcc version 2.95.4 20011002 (Debian prerelease) > GNU gdb 2002-04-01-cvs I am always sceptical about distributions prerelease or patched versions. I am not really a C++ expert but I lurk on GCC list and so know that exceptions were/are a little "fluid" in their implementation. It would be easy for an ad. hoc. "prerelease" to have grabbed an inconsistent set of patches. > >I installed the aspell/pspell code from source on all machines. > >So it's a bit odd that it works on my SuSE machine but aborts on the >Debian. Not a lot of difference. My opinion is that SuSE tends to be better quality controlled than even RedHat and that Debian does a good job at getting "latest" stuff. >Could be a missing library, I suppose, >but I don't know how to detect this. (My use of) gdb, strace and ltrace >have not helped. > >And I just don't know what to thing about PERL_DL_NONLAZY. I thought all >that did was set a flag (RTLD_NOW) on dlopen calls made by perl. So it >seems odd that would effect the c++ code at all. > >I just now build Perl 5.7.3 on Debain and it's exactly the same problem. Which is good ;-) (at least from the perl point of view) and points at it being a Debian problem not a perl-xs problem. > >This works: > >PERL_DL_NONLAZY=0 /home/moseley/perl/ithread/bin/perl5.7.3 -I'blib/lib' >-I'blib/arch' t/test.t > >This does not (e.g. "Aborted") What PERL_DL_NONLAZY=1 does is insist that all the symbols your loadable needs are resolved - or it aborts. It should report which symbol it thought was missing. It may be that on non-ELF systems C++'s desire for "weak refs" (I concept I don't fully understand myself) confuses dynaloader into thinking you _need_ something you don't really. The PERL_DL_NONLAZY=0 case may work if particular .t file does not call the missing function. If dlopen() doesn't report the missing function then using nm on the .so file created from your XS and grep'ing for ' U ' will list symbols that are "needed" you can then compare those exported by perl executable and see what is "missing". > >PERL_DL_NONLAZY=1 /home/moseley/perl/ithread/bin/perl5.7.3 -I'blib/lib' >-I'blib/arch' t/test.t -- Nick Ing-Simmons http://www.ni-s.u-net.com/
