On 12/28/10 21:55, David Southwell wrote:
> > > On 12/27/10, David Southwell <da...@vizion2000.net> wrote:
> > > >> On 12/27/10, David Southwell <da...@vizion2000.net> wrote:
> > > > Agreed - but following Doug's commit I can vouch that the
> > > > PERL_THREADED hack
> > > > was still needed for 7.2 p3 systems on amd64.
> > >
> > > It shouldn't be needed. Can you remove this definition from any
> > > locally-modified Makefiles, and provide the same information
that was
> > > requested from Da Rock? (Why do I feel like a WWE announcer when I
> > > type that? ...)
> > >
> > > b.
> >
> > I do not want to rebuild WITHOUT_IMAGEMAGICK_PERL on a running system
> > with active user access which needs perl.
> >
> > Have you got the replies from Da Rock?
>
> Before going any further I would suggest that Da Rock be advised to
update
> his ports tree followed by
>
> # pkgdb -F
> Fix any problems then. If there are any problems he cannot fix at this
> stage then report those. Then:
>
> # portmaster -a or portupgrade -a
>
>
> If he gets any failure which may possibly be linked to a Perl problem he
> should rebuild perl with upward and downward recursion. e.g
> #portupgrade -rR lang/perl5.8
I dare say I'd come back with an error given I have 5.10 installed on
the system.
>
> Until that is completed any other report could send us off on a wild
goose
> chase.
>
> My twopennorth
>
I can do what you suggested when we have a report from Da Rock with
his results from a system with thoroughly updated ports. My guess is
that his probs will be solved by the above.
Ok, so it took a while and I'm still reviewing some other issues. The
real problem is that the error msg sends all on a wild goose chase. I
got it updated but the problem had absolutely nothing to do with perl,
djvu, and their threads.
After some scratching about with configs and Makefiles, I discover there
is an option not selected (not sure why) dealing with ImageMagick's
threads- not perls or djvus! Now, IF those options are selected (and
remember this is an upgrade) why not assume threads and print an info
msg saying so? And why does the error msg not even allude to this
instead of sending everyone on a chase after a mythical error that is
not even the fault of the dependency?
Thanks for the hints guys, but I'm now trying to figure a method that
may resolve this type of issue in the future- I remember using dialog
boxes in extremely old installs of linux (and BSD packages I think) that
automatically selects or deselects based on a selections
required/incompatible dependencies. That would save hours of fart-arsing
about for many- even searching for known answers takes time, easily
resolved if something stable can be figured this way.
Thanks again.
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
