267416 - We need a high version perl to build firefox.

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Leon Sha]

It is OK if we build mozilla using perl version 5.0005.
But when we build firefox using this perl, the build failed.
If we use perl version 5.6.1, there will be no problem.

Comment 1

[Leon Sha]

Attachment: This is errors.

Comment 2

[Leon Sha]

Attachment: Patch to change the configure

Comment 3

[Brian Ryner (not reading)]

Comment on attachment 164349 [details] [diff] [review]
Patch to change the configure

-> bsmedberg, because I think he has a better idea what the current situation
is with preprocessor.pl's perl requirements

Comment 4

[Brian Ryner (not reading)]

Comment on attachment 164349 [details] [diff] [review]
Patch to change the configure

dbaron, any thoughts on this?  Would this require updating build machines?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 164349 [details] [diff] [review]
Patch to change the configure

This might require updating otaku or something like that.  Is the issue
actually the perl version rather than a module version or something like that? 
(I guess it appears that way.)

Comment 6

[Leon Sha]

Attachment: Ready to check in

Should I check in the patch now?

Comment 7

[Leon Sha]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1407; previous revision: 1.1406
done
Checking in configure;
/cvsroot/mozilla/configure,v  <--  configure
new revision: 1.1384; previous revision: 1.1383
done

Comment 8

[Boris Zbarsky [:bzbarsky]]

Looks like btek needs to be updated too...

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This should be backed out.  We really can't do things like that to btek (it has
a cascade of effects), so as long as we want btek to be a constant yardstick, we
can't do this.

Comment 10

[Leon Sha]

Back out done.

Comment 11

[Glenn Schrader]

(In reply to comment #10)
> Back out done.

I ran into the same problem while attempting to build Thunderbird. The build
failed for me when it attempted to run make-jars.pl. The failure is due to the
way that getopts parses command line arguments. The Makefiles use -- to
terminate getopts argument processing but getopts in the earlier version of perl
doesn't stop there. Some of the remaining arguments look like command line
switches, getopts complains about them not being in its config string, and the
script becomes very confused. Just to make sure I checked the code for getopts
from perl versions 5.005 and 5.8.6. The code in 5.8.6 has the test for "--" and
the code for 5.005 doesn't.

Comment 12

[David G King]

Surely this is no longer a bug?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Why not?  What's changed?

Comment 14

[cls]

Attachment: v1.1

This is silly.  We shouldn't be holding out on fixes just because one tinderbox (of dubious value) has unique constraints that only apply to it.  If we ever start using XULPPFLAGS in SeaMonkey (maybe when SM starts using toolkit), then btek will hit this problem as well.

This patch bumps the required version to 5.6.0 and wraps the perl version check in a TINDERBOX_SKIP_PERL_VERSION_CHECK test. btek's tinderbox config needs to be updated to set that variable.

Comment 15

[cls]

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla&file=&filetype=match&who=cls%25seawood.org&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-11+20%3A03%3A00&maxdate=2007-02-11+20%3A05%3A00&cvsroot=%2Fcvsroot