[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fix for user-build of Digest::MD5



On Wed, Jun 11, 2003 at 11:27:58AM -0400, Soren Andersen wrote:
>On Tue, Jun 10, 2003 at 05:26:00PM +1000, Brendan O'Dea wrote:
>> On Sat, May 31, 2003 at 02:36:23AM -0400, Soren Andersen wrote:
>> >I've repeatedly run across a little "build bug" with CPAN module
>> >"Digest::MD5" (at v2.24 now I think) which will prevent the user / admin
>> >trying to install it using CPAN or manually, from getting a "clean" run.
>> >This sort of thing bothers me. I did something about it: made a patch.
>> >That patch is attached to this message.
>> 
>> It's not entirely clear exactly *what* your build bug is.
>
>I shall try to describe it from memory then.
>
>
>In this module, the author has written a Makefile.PL that tries to
>compile and run a little test program (some C code) before writing the
>Makefile (by calling WriteMakefile() as usual). On Debian, this test
>compilation phase returns failure because the gcc (cc) command being
>issued is calling for the inclusion in the link step, of every lib
>linked into Perl at build-time. That includes "-lgdb" and another (at
>least) database-library-related lib that isn't installed (isn't findable
>on the system, by gcc-running-ld).

Ah, I see.  Thank you for your detailed respnse.  The problem was not
apparent for me since I (unsurprisingly) have perl's build-depends
installed.

I would suggest a simpler patch:

--- Makefile.PL.orig	2003-01-19 15:38:57.000000000 +1100
+++ Makefile.PL	2003-06-12 23:47:58.000000000 +1000
@@ -105,7 +105,7 @@
 	$cc_cmd .= " -o $exe";
     }
     my $rc;
-    $rc = system("$cc_cmd $Config{ldflags} u32align.c $Config{libs}");
+    $rc = system("$cc_cmd $Config{ldflags} u32align.c $Config{perllibs}");
     if ($rc) {
 	print "Can't compile test program\n";
 	unlink("u32align.c", $exe, "u32align$Config{_o}");

perllibs is a recent addition to %Config whcich contains the subset of
libraries which are directly linked to perl (as opposed to those ehich
are requirements of dynamically loaded modules).

>Another dimension to this problem is that it possibly reflects what some
>could interpret as a dependencies-tracking failure in the Debian Perl
>package (which is one reason I wanted to bring it to public attention).
>It is possible (TTBOMU) that installing the *-dev packages for some db
>libraries linked into Debian's Perl at package build time would silence
>the build-time noise for Digest::MD5; i.e. what gcc-running-ld is
>squawking about is missing libs because of uninstalled *-dev files.

I don't believe that it's witin the scope of the Perl packaging to
handle the build dependancies of all modules downloaded from CPAN,
particularly since it is the purpose of most XS modules to interface
with arbitrary C libraries.

>You wrote:
>> The only issue that I can find with a local installation of Digest::MD5
>> is that the maintainer sets INSTALLDIRS to "perl" in the Makefile.PL for
>> 5.8.0+, meaning that "make install" will attempt to install under
>> /usr/{share,lib}/perl .
>> 
>>     make install INSTALLDIRS=site
>> 
>> works fine.
>
>
>The setting of the INSTALLDIRS isn't the build bug, but does have
>significance. I think most users on Debian would want to do as you
>advise in order to prevent their upgraded module from being clobbered
>silently by an APT package operation sometime in the future.

Not necessarily, I discovered the problem (which stems from the fact
that this module is included as part of recent perl versions) since I
did not have write permission on /usr/{share,lib}/perl since I was not
running the build as root.

Note: on Debian systems, users in group "staff" may write to /usr/local,
a feature which interoperates very well with the CPAN module and
insulates you to some degree from such problems.

--bod



Reply to: