On Sun, Feb 19, 2012 at 04:00:42AM +0100, Marco d'Itri wrote: > On Jan 15, Marco d'Itri <m...@linux.it> wrote: > > > > at least #649759 suggests this might be related to not using all > > > the compilation flags from ExtUtils::Embed, '-D_LARGEFILE_SOURCE > > > -D_FILE_OFFSET_BITS=64' in particular. Indeed, I see the inn2 'configure' > > > script chops those away. > > I removed the flags because generally enabling LFS would create an inn > > package which cannot read the on-disk data written by the precedent > > release, and for which there is no conversion tool. > > So I need to find out if the internal INN ABI between the perl bits and > > the rest of the program depends on LFS. > This is not going to be easy. Are you totally sure that there is no > other option than building with LFS all code which includes perl > headers?
At least all code that accesses a PerlInterpreter struct, AFAICS. The problem is that the PerlInterpreter struct has two members of type "Stat_t" (see intrpvar.h) , which is a "struct stat" on unix and so varies in size depending on the LFS flags. All the later interpreter specific variables in the struct are accessed at a wrong offset if those flags don't match the ones libperl was built with. 'PL_sv_undef' is one of these variables, and the 'Bizarre copy of unknown' error comes from a sanity check inside the sv_setsv() call because the wrong PL_sv_undef doesn't make any sense. I guess you could work around that sanity check with the 'body = &PL_sv_undef' trick, but I'd expect other problems later. Sorry, no better ideas. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
