Oddly enough, installing Perl 5.8 from source on a virgin RedHat 8.0 system
fails with this mysterious error:
make: *** No rule to make target `<built-in>', needed by `miniperlmain.o'.
Stop.
Anyone seen this?
Lincoln
On Tuesday 18 March 2003 11:41 am, Cosby, Christopher wrote:
> Out of curiosity, have you tried installing the ActiveState-5.8 RPM and
> doing the testing? It seems like an easy way to test your theory of
> $platforms{'RedHat8.0'}->sucks = 1, as it installs in (I speak for the
> .deb) /usr/local/ActivePerl-5.8 and is self-contained, so it can be
> installed alongside the RedHat default package. Methinks it's at least
> worth a shot.
>
> http://www.activestate.com/Products/Download/Register.plex?id=ActivePerl
>
> Christopher S. Cosby
> SciCare Software Services
> 770.236.1128
>
> > -----Original Message-----
> > From: Thomas Good [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, March 18, 2003 10:53 AM
> > To: Tim Bunce
> > Cc: Jarkko Hietaniemi; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: Using perl 5.8.0?
> >
> > On Tue, 18 Mar 2003, Tim Bunce wrote:
> > > Thomas, did you get round to doing this?
> > >
> > > Tim.
> >
> > Hi Tim,
> >
> > I have worked on it a bit...
> >
> > I attempted to reproduce the problem here at work on a test
> > machine running
> > slackware 8.0. I installed perl 5.8.0 and built. No errors.
> > Then I recalled
> > that Redhat (in their wisdom) built the default perl 5.8
> > install with the
> > multi-threading turned on. I edited the Makefile and built
> > again. Still no
> > errors on slackware. So, I have been reading through all of
> > the patches, etc,
> > that redhat applied to the perl src to try and see what they
> > did that may
> > have caused this.
> >
> > I rebuilt perl from the src rpm on my redhat machine at home
> > and turned off
> > multi-threading. My script still hangs. So, I have no idea
> > what is going
> > on. Here at work we run slackware on all boxes except the
> > IBM machine that
> > has an LSI SCSI card (unsupported by slackware 8.x) and this
> > machine was the
> > one that had trouble. It now runs redhat 7.3 and perl 5.6.1
> > so it works fine.
> >
> > In the interests of reproducing the problem I installed
> > redhat 8.0 on the
> > a test box at home. No difficulty whatsoever in reproducing
> > the error. I
> > tried to rebuild DBI as you suggested but ran into the usual
> > errors from
> > redhat (broken dependency hell, as they cannot leave well
> > enough alone).
> > That's as far as I've gotten.
> >
> > To recap:
> >
> > 1. I cannot reproduce this problem on slackware.
> > 2. The problem is easily reproduced on redhat 8.
> > 3. Redhat does all kinds of odd things to the perl src (and
> > makes all sorts
> > of cute/disparaging comments in the code whilst doing so)
> > and this appears
> > to have either created or exacerbated the problem that is
> > causing my
> > scripts to hang.
> >
> > I will try some more to get RH8 to agree to let me replace
> > the rpm dbi with
> > a build that has your suggestions in place and then get back to you.
> >
> > Sorry for the delay, very busy...
> >
> > Cheers.
> >
> > > On Wed, Feb 26, 2003 at 10:54:12AM +0000, Tim Bunce wrote:
> > > > On Tue, Feb 25, 2003 at 05:30:31PM -0500, Thomas Good wrote:
> > > > > On Tue, 25 Feb 2003, Tim Bunce wrote:
> > > > > > > While I was using 5.8 large data transfers via DBI
> >
> > failed consistently.
> >
> > > > > > > I have compared notes with others (including
> >
> > Lincoln Stein) and this
> >
> > > > > > > problem is easily reproduced. In fact, I can't
> >
> > stop reproducing it. ;-)
> >
> > > > > > A self-contained test case would be ideal!
> > > > >
> > > > > Hi, I will try to put this together, meanwhile here is
> >
> > a summary:
> > > > > I have a postgres table with 220 individual patient skills -
> > > > > these skills become questions on a long form. Another table
> > > > > holding live patient records is queried and the returned values
> > > > > serve as popup_menu() defaults
> > > > >
> > > > > Tr ( td ( "$skill[0]" ) <--
> >
> > Here is the string/question
> >
> > > > > td ( popup_menu( ...
> > > > > -values=>['1 - Excellent', '2 -
> >
> > Adequate', '3 - Needs Attention',
> >
> > > > > '4 - Needs Immediate
> >
> > Attention', '5 - Not Applicable'],
> >
> > > > > -default=>"$row->{item_01}" <--
> >
> > Here is the returned value
> >
> > > > > ...
> > > > >
> > > > > On wellworn test equipment (all ide, 64M RAM, clock
> >
> > speed of 300MHz) running
> >
> > > > > Slackware 8.1, perl 5.6.1, DBI 1.25, Apache 1.3.26,
> >
> > DBD-Pg 1.21, Postgres 7.3.1
> >
> > > > > this script runs.
> > > > >
> > > > > On a brand new IBM eServer (LSI SCSI, 512M RAM, 2 GHz
> >
> > clock) running Redhat 8.0,
> >
> > > > > perl 5.8.0, DBI 1.28, Apache 2.0.40, DBD-Pg 1.21 the
> >
> > script hangs.
> >
> > > > > I tried commenting out the defaults, etc. Only
> >
> > removing both queries allowed
> >
> > > > > the script to run. The CGI form was not a problem,
> >
> > even when I doubled the
> >
> > > > > length as a test.
> > > >
> > > > Enable tracing to a log file (eg set DBI_TRACE env var to
> >
> > something
> >
> > > > like "6=/tmp/dbi.log") and then run the script using truss
> > > > (or similar tool that shows operating system calls).
> > > >
> > > > As a (better) alternative to using truss you could do a kill -QUIT
> > > > on the process once it has hung and then get a stack
> >
> > trace from the
> >
> > > > core file.
> > > >
> > > > That would be useful, but to be *really* helpful the DBI
> >
> > and DBD::Pg
> >
> > > > would need to be compiled and linked with debugging enabled (ie -g
> > > > option to the compiler/linker).
> > > >
> > > > For the DBI you can do that by simply rebuilding it starting with
> > > > "perl Makefile.PL -g".
> > > >
> > > > For DBD::Pg you may need to run "perl Makefile.PL" and
> >
> > then hack the
> >
> > > > generated Makefile: Add -g as an option on the "CCCMD = $(CC) ..."
> > > > line and also to the "OTHERLDFLAGS =" line.
> > > >
> > > > Once you've got the core file you can get a stack dump
> >
> > using a debugger
> >
> > > > like gdb ("gdb /path/to/the/perl/you/used /path/to/core"
> >
> > then "bt".)
> >
> > > > Tim.
> >
> > --------------------------------------------------------------
> > ---------
> > Thomas Good e-mail:
> > [EMAIL PROTECTED]
> > Programmer/Analyst phone: (+1)
> > 718.818.5528
> > Residential Services fax: (+1)
> > 718.818.5056
> > Behavioral Health Services, SVCMC-NY mobile: (+1)
> > 917.282.7359
> >
> > // Bitte nicht vergessen: der Kindermord bei Ypern. Nie Wieder Krieg!
>
> - - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
> This e-mail and any attachments may contain information which is
> confidential, proprietary, privileged or otherwise protected by law. The
> information is solely intended for the named addressee (or a person
> responsible for delivering it to the addressee). If you are not the
> intended recipient of this message, you are not authorized to read, print,
> retain, copy or disseminate this message or any part of it. If you have
> received this e-mail in error, please notify the sender immediately by
> return e-mail and delete it from your computer.
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
========================================================================
