Bug #6039 for Convert-UUlib: crc32 symbol clashes in Convert::UUlib and Compress::Zlib on OS X

Fri Apr 16 15:47:15 2004 Guest - Ticket created

Subject:

crc32 symbol clashes in Convert::UUlib and Compress::Zlib on OS X

Bug: both Compress::Zlib and Convert::UUlib wind up having exported _crc32 symbols in their dynamic libraries on OS X 10.2.8, which seems to kill applications trying to use both. I fixed this for myself by renaming function crc32() in crc32.c (and crc32.h and callers) to uu_crc32. I don't know enough about C or linking or OS X to know if this clash "shouldn't" have happened. Example: Using OS X 10.2.8, Perl 5.8.3, Convert::UUlib 1.01, Compress::Zlib 1.33, and amavisd-new 20030616p9, I got this error: $ /usr/local/sbin/amavisd start dyld: perl multiple definitions of symbol _crc32 /usr/local/lib/perl5/site_perl/5.8.3/darwin/auto/Convert/UUlib/UUlib.bundle definition of _crc32 /usr/local/lib/perl5/site_perl/5.8.3/darwin/auto/Compress/Zlib/Zlib.bundle definition of _crc32 Trace/BPT trap

Sun Apr 18 10:44:30 2004 pcg [...] goof.com - Correspondence added

Date:	Sun, 18 Apr 2004 16:44:33 +0200
From:	<pcg [...] goof.com ( Marc) (A.) (Lehmann )>
To:	Guest via RT <bug-Convert-UUlib [...] rt.cpan.org>
CC:	undisclosed-recipients: ;
Subject:	Re: [cpan #6039] crc32 symbol clashes in Convert::UUlib and Compress::Zlib on OS X
RT-Send-Cc:

On Fri, Apr 16, 2004 at 03:47:23PM -0400, Guest via RT <bug-Convert-UUlib@rt.cpan.org> wrote: Show quoted text

> Bug: both Compress::Zlib and Convert::UUlib wind up having exported _crc32 symbols in their dynamic libraries on OS X 10.2.8, which seems to kill applications trying to use both. I fixed this for myself by renaming function crc32() in crc32.c (and crc32.h and callers) to uu_crc32. I don't know enough about C or linking or OS X to know if this clash "shouldn't" have happened.

Assuming that this is no bug (omission of flag values etc.) in perl, then this is yet another shortcoming in darwin that is not fixable. I can rename the crc symbol in Convert::UUlib at the expense of slightly increased maintainance effor in the future (and likewise could do zlib), but this is a workaround, not a fix. The fix would be to handle multiple symbols correctly (i.e. locally within each loadable object unless told otherwise). -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |

Mon Dec 05 18:57:17 2005 MLEHMANN [...] cpan.org - Status changed from 'new' to 'resolved'