Closed Bug 448573 Opened 16 years ago Closed 12 years ago

configure fails - can't parse "$GCC -v" and retrieve version number with French VC8


(Firefox Build System :: General, defect)

Windows XP
Not set


(Not tracked)



(Reporter: mozilla, Assigned: heycam)




(5 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008073015 Minefield/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008073015 Minefield/3.0.1

cl.exe -v outputs this:
"Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version 14.00.50727.762 pour 80x86
Copyright (C) Microsoft Corporation. Tous droits réservés."

_CC_MAJOR_VERSION variable is empty and configure exits with message "configure: error: This version of the MSVC compiler, $CC_VERSION , is unsupported."
The installed version of Visual Studio is "Microsoft Visual Studio 2005 - Français"

replacing lines 3006 and 3013 respectively with:

Possible fix:
modify the _MSVC_VER_FILTER regex to support any language

Reproducible: Always

Expected Results:  
The right version number should be set for the CC_VERSION and CXX_VERSION variables.
I've seen this mentioned in the forums before, but I don't think it's ever been reported. I don't know what's actually failing here. Maybe you could figure out why that regex *doesn't* match the output you pasted there?
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
I changed two regex used to parse the cl.exe, link.exe and mt.exe version numbers. They now rely on the word "version" (without the v) preceding the numbers.

On a french system, one or many 'ÿ' chars were printed between "version" and "14.00..." instead of an empty space. We can assume the "ersion" string won't be different on systems with other encodings/languages.
Attachment #331858 - Flags: review?(ted.mielczarek)
@see attachment 331858 [details] [diff] [review]
Attachment #331859 - Flags: review?(ted.mielczarek)
Comment on attachment 331859 [details] [diff] [review]
generated with autoconf2.13 on a linux system

You don't need to submit patches to configure, is enough.
Attachment #331859 - Attachment is obsolete: true
Attachment #331859 - Flags: review?(ted.mielczarek)
Comment on attachment 331858 [details] [diff] [review]
fix - supports any char instead of ' ' in the regex

I don't see how this regex can possibly work. You're trying to match "version 14.00.50727.762" with the regex ".*ersion[^0-9]+((?[0-9]+\.)*[0-9]+).*", which looks very wrong.
Attachment #331858 - Flags: review?(ted.mielczarek) → review-
Attached image tested regex
Regex works perfectly, it has been tested by building Firefox on a Windows machine. I also tested it didn't impact my Linux build.
You can test the regex at
The '?' char might be optional but i placed it there to ignore the grouping create by first set of parenthesis.

The regex works, you might want to try it out yourself at
I've had someone come to me with build problems with a French version of MSVC 2010 that is exactly this problem -- a ÿ character used just before the version number in the compiler's banner rather than a space.  ("ÿ" of course being Unicode character 255, which if interpreted in CP437 is a non-breaking space.)

I am having trouble exactly matching the ÿ, but how about we change the regular expression to allow a space or any non-ASCII character as the delimiter just before the version number?
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → cam
Attachment #632163 - Flags: review?(ted.mielczarek)
Comment on attachment 632163 [details] [diff] [review]

Review of attachment 632163 [details] [diff] [review]:

@@ +678,4 @@
>          AC_LANG_RESTORE
>          changequote(,)
> +        _MSVC_VER_FILTER='s|.*[^!-~]([0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?).*|\1|p'

I guess this is fine. Honestly, we probably don't need the space check at all. Matching 3-4 groups of numbers separated by periods is probably sufficient.

You'll need to make this change in js/src/ as well. It looks like NSPR's configure has this same check, but it doesn't explicitly error out for unrecognized versions, so you might not need to change that.
Attachment #632163 - Flags: review?(ted.mielczarek) → review+
Attached patch patch v1.1Splinter Review
OK.  There is some behaviour that switches depending on what the detected version is in nsprpub, so let's fix it there too.  I'll take your r+ as applying to the nsprpub/ too, and r?dmandelin for js/src/
Attachment #632163 - Attachment is obsolete: true
Attachment #635560 - Flags: review?(dmandelin)
Attachment #635560 - Flags: review?(dmandelin) → review+
Ever confirmed: true
Oh, I'm sorry, I wasn't clear. NSPR still lives in CVS, so we have to land the patch there and sync it back to m-c with a tagged revision. If you attach a separate NSPR patch I'll land it in CVS for you.
(Also my review is fine for js/src/ as well, it's all build system.)
Attached patch patch to nsprSplinter Review
Oops, I think I knew that but forgot.  Good thing too, as I made a stupid c/p error in the original patch to nsprpub/  This one should be good.
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Attached patch nsprpub-typoSplinter Review
(In reply to Ed Morley [:edmorley] from comment #15)

There is a typographical error in nsprpub/
Ted, will the NSPR update and relanding in m-c happen soon, or should I fix up this nsprpub/ problem first?  (Not sure whether it is causing a problem at the moment.)
MSC_VER is undefined!

MSC_VER is used in nsprpub/pr/src/misc/
$(OBJDIR)/prdtoa.$(OBJ_SUFFIX): prdtoa.c
ifeq (,$(filter-out 1100 1200 1300 1310,$(MSC_VER)))
	$(CC) -Fo$@ -c $(CFLAGS) -Op $(call pr_abspath,$<)
	$(CC) -Fo$@ -c $(CFLAGS) -fp:precise $(call pr_abspath,$<)
Blocks: 767848
Yeah, fair enough.  Filed bug 767848 to backout the nsprpub/ change.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.