Re: Fix for user-build of Digest::MD5
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).
If you were able to parse that previous dense para (I am sure that for
many readers a transcript of the build session would have been
preferable, and I'll try to provide one soon), you may leap to the
insight that the author's Makefile.PL is getting info about what
libraries to link in from Config.pm. My fix removes from the data being
passed to gcc-running-ld, mention of any "-lfoo" libs where "foo" has
anything to do with databases, which can have nothing to do with
resolving needed symbols in Digest::MD5 or its pre-build test program.
Basically its just a messy, raw kludge in the author's Makefile.PL which
is trying to work around some problem encountered on some other odd
platform (not Linux) that is causing all this trouble. Conditional code
to exclude the entire test-compilation step if the platform is "linux"
(or better, if the platform is known to not *need* the test it's
excluded by default) would be a different and probably better way to
approach this. I invite readers to look at the Makefile.PL for the
module themselves to see if my analysis is correct, I cannot be 100%
sure since I am not familiar with the underlying portability issue that
the author is grappling with.
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.
As you are all doubtless aware, many packages relating to many different
things on Debian, have a "run-time" component and a "development"
component. By "component" I mean that some stuff like static libs and
headers are not part of the main package but reside in a separate
package usually named (in the Debian package naming scheme) like
"libfoo-dev" if the main package is "libfoo". One could argue that the
failure of a module to be building cleanly, like this failure here, is
the "fault" of the Debian perl package maitainer for not making the
"libfoo-dev" packages required dependencies of Perl on Debian. *I* am
not saying that, but someone perhaps could.
I have been using Perl a lot longer than I've been using Debian and one
reason I wanted to post this is to get feedback to correct any possible
misunderstandings I may have about some aspect of Debian, it's package
management or GNU/Linux platform issues in general.
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.
--
See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint | "Only when efforts to reform society have as
BD26 A5D8 D781 C96B 9936 | their point of departure the reformation of
310F 0573 A3D9 4E24 4EA6 | the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security."
-- Daisaku Ikeda
Reply to: