tags:

views:

166

answers:

2

Hi there,

I've been trying to get SVN to connect to Atlassian Crowd for authentication but have been running into issues with OS X Leopard Server (10.5.8) and Perl's Digest::SHA1.

I've installed it from the source (http://search.cpan.org/~gaas/Digest-SHA1-2.12/SHA1.pm) and if I call it directly from a Perl script it works fine, but in my apache logs I get this error:

failed to resolve handler `Apache::CrowdAuth': Can't load '/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle' for module Digest::SHA1: dlopen(/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle, 1): no suitable image found.  Did find:
    /Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle: no matching architecture in universal wrapper at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm line 230.
 at /Library/Perl/5.8.8/Cache/FileBackend.pm line 15
Compilation failed in require at /Library/Perl/5.8.8/Cache/FileBackend.pm line 15.
BEGIN failed--compilation aborted at /Library/Perl/5.8.8/Cache/FileBackend.pm line 15.
Compilation failed in require at /Library/Perl/5.8.8/Cache/FileCache.pm line 20.
BEGIN failed--compilation aborted at /Library/Perl/5.8.8/Cache/FileCache.pm line 20.
Compilation failed in require at /Library/Perl/5.8.8/Apache/CrowdAuth.pm line 8.
BEGIN failed--compilation aborted at /Library/Perl/5.8.8/Apache/CrowdAuth.pm line 8.
Compilation failed in require at (eval 2) line 3.

Unfortunatley there doesn't seem to be any documentation on the error online.

Any ideas?

+2  A: 

It seems that there is a mismatch in the compiler architecture triplet between modperl and the Perl executable. The relevant error is really just the "no matching architecture in universal wrapper", which seems to be completely OS X specific.

Are you using MacOS perl? Try building and installing a different perl, it is known that Apple did a terrible job in their perl build.

Daniel Ruoso
Yeah, i'm just using the Perl install that comes with OS X.I'll try a custom build and let you know how I go.
d2kagw
"it is known that Apple did a terribly job in their perl build" -- citation needed.
Ether
http://www.theregister.co.uk/2009/02/16/apple_update_perl_breakage/Note that Tatsuhiko Miyagawa, who's described as just a blogger in the article, is actually a well-known figure in the Perl community.
Kinopiko
@Ether: Add these - http://www.theregister.co.uk/2009/03/23/apple_perl_breakage_apology/, http://perlbuzz.com/2007/12/64bit-macs-may-have-cpan-build-problems.html, http://perlbuzz.com/2009/02/mac-os-x-security-update-2009-001-might-break-your-perl.html, http://bulknews.typepad.com/blog/2009/02/mac-os-x-security-update-2009001-breaks-perl-cpan.html
Telemachus
Thanks for the links! I guess it's time for me to clear out my old perl installations and start anew, again.. :D
Ether
I've custom compiled Perl and mod_perl but i'm still getting the same errors - it seems as though the new mod_perl is still looking at the old install path (even though it was compiled with the new path)
d2kagw
+2  A: 

While looking for links to show Ether, I found this post which may be relevant. It's a bit old, but the mention of Apache caught my eye, since it's part of your problem:

If you've recently migrated from a 32-bit Mac to a 64-bit model, you may have run into problems with some of your Perl modules suddenly throwing up their hands and going "wha?" An AFP548 article points out the likely culprit: CPAN on the Mac compiles all of your modules as Universal 32-bit binaries by default, which tends to disappoint 64-bit applications such as Apache 2.0's mod_perl.

The fix mentioned there is to adjust your ARCHFLAGS variable. The Ars Technica post points to this link for more.

Telemachus