So it's "well-known" to those that know that selftest suites ('make
test') of the -pm5100 variant of many perlmodule packages fails on OS
X 10.6 when fink is configured for 32-bit (arch i386). If you didn't
know, now you do. I spent a few hours hacking the internals of
ExtUtils::MakeMaker and Test::Harness, and didn't solve it but figured
I may as well post what I found and some possible solutions. If none
of the preceding paragraph makes any sense to you, you may as well
stop reading now.
The key observation is that during the running of the test scripts,
it's as if the "use 32-bit mode" control is ignored. If the module
being tested has q compiled C code, attempts to load it fail, for
example, in sub-name-pm5100-0.04-1:
PERL_DL_NONLAZY=1 /usr/bin/arch -i386 perl5.10.0 "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/smoke.t .. Can't load
'/sw/build.build/sub-name-pm5100-0.04-1/Sub-Name-0.04/blib/arch/auto/Sub/Name/Name.bundle'
for module Sub::Name:
dlopen(/sw/build.build/sub-name-pm5100-0.04-1/Sub-Name-0.04/blib/arch/auto/Sub/Name/Name.bundle,
2): no suitable image found. Did find:
/sw/build.build/sub-name-pm5100-0.04-1/Sub-Name-0.04/blib/arch/auto/Sub/Name/Name.bundle:
mach-o, but wrong architecture at
/System/Library/Perl/5.10.0/darwin-thread-multi-2level/DynaLoader.pm line 207.
at t/smoke.t line 6
even though "/usr/bin/arch -i386" causes perl5.10.0 to run in i386
mode and 'file' says that's the arch that the .bundle is. A similar
effect happens if the test script itself loads a fink-supplied
external (actually installed) other module that is arch-specific: the
(sub)module load fails with various arch-mismatch symptoms.
Diving into Test::Harness, turns out tests are done in a sandbox
subprocess that is run with *just* the perl-interp command-name. The
/usr/bin/arch wrapper is not present, so "perl5.10.0" is running in
64-bit (native arch) mode, which obviously doesn't match the 32-bit
arch for which our single-arch modules are built. Overloading the
interp name to be "/usr/bin/arch -386 perl5.10.0" won't work because
the interp name is treated as a single command (gets quoted to protect
against whitespace in the path).
Three solutions:
1. Hack TAP::Parser::SourceHandler::Perl::_get_command_for_switches()
on 10.6/i386 (not sure if others must or should-for-consistency or
must-not have similar trick):
- my @command = ( $command, @switches, $file, @args );
+ my @command = ( '/usr/bin/arch', '-i386', $command, @switches, $file,
@args );
Tested, and it seems to work. Would be easy to "strongly suggest" that
maintainers BuildDepends on test-harness-pmXXX>=WHATEVER to get this
magic.
2. Figure out a shell env var or other way to make sure that the
spawned interp is run with the correct arch. At various times in
various contexts, we use ARCHFLAGS="" (I think that only affects the
compiling of C-code modules?). That is always fragile because we rely
on apple not to change how it works, but avoids having to perpetuate a
hacked perl-module package.
3. Write a wrapper for system perl5.10.0 on 10.6 that runs the actual
interp via a /usr/bin/arch wrapper, just another like we do for the
compilers in path-prefix-10.6. Would just need to overload PATH during
the test spawning. And don'cha know? Appears that PATH is getting
sanitized...somewhere...during the tests (env in TestScript is not
propagated into the _get_command_for_switches() spawn), so still seems
like we'd need to be hacking the Test::Harness guts.
dan
--
Daniel Macks
dma...@netspace.org
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
