Closed Bug 617272 Opened 9 years ago Closed 9 years ago

AIX compilation error for Firefox-3.6.12 source storage/src/variantToSQLiteT_impl.h", line 56.12: 1540-0274 (S) The name lookup for "sqlit e3_T_null" did not find a declaration

Categories

(Toolkit :: Storage, defect)

1.9.2 Branch
PowerPC
AIX
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b10
Tracking Status
blocking2.0 --- -
blocking1.9.2 --- -
status1.9.2 --- .14-fixed
status1.9.1 --- unaffected

People

(Reporter: sehgal.himanshu01, Assigned: ul-mcamafia)

References

Details

(Keywords: verified1.9.2)

Attachments

(3 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) FBSMTWB
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) FBSMTWB

While compiling Mozilla Firefox-3.6.12 on AIX, get the following error :

"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 70.14: 1540-0274 (S) The name lookup for "sqlit
e3_T_int" did not find a declaration.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 70.14: 1540-1292 (I) Static declarations are no
t considered for a function call if the function is not qualified.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 80.14: 1540-0274 (S) The name lookup for "sqlit
e3_T_int64" did not find a declaration.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 80.14: 1540-1292 (I) Static declarations are no
t considered for a function call if the function is not qualified.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 88.14: 1540-0274 (S) The name lookup for "sqlit
e3_T_double" did not find a declaration.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 88.14: 1540-1292 (I) Static declarations are no
t considered for a function call if the function is not qualified.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 109.14: 1540-0274 (S) The name lookup for "sqli
te3_T_text" did not find a declaration.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 109.14: 1540-1292 (I) Static declarations are n
ot considered for a function call if the function is not qualified.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 123.14: 1540-0274 (S) The name lookup for "sqli
te3_T_text16" did not find a declaration.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 123.14: 1540-1292 (I) Static declarations are n
ot considered for a function call if the function is not qualified.
"/build/ffox-3612/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 149.16: 1540-0274 (S) The name lookup for "sqli
te3_T_blob" did not find a declaration.

Reproducible: Always

Steps to Reproduce:
1.Build Mozilla Firefox-3.6.12 on AIX using Gnome 64 bit RPMS.
2.
3.
Actual Results:  
The build fails with the above error message

Expected Results:  
Build should complete without any error
blocking1.9.2: --- → ?
blocking2.0: --- → ?
OS: Other → AIX
Version: unspecified → 3.6 Branch
Component: Build Config → Storage
Product: Firefox → Toolkit
QA Contact: build.config → storage
Version: 3.6 Branch → 1.9.2 Branch
Not blocking a branch release for an unconfirmed bug on a non-Tier-1 platform. If someone writes a patch and gets it tested we can approve it.
blocking1.9.2: ? → -
I haven't found time for 1.9.2 branch porting by now, and if I had time I would focus on Firefox 4.0 instead.
But nonetheless, IBM's XLC/C++ compiler shows up bugs in the source, that less strict compilers like GCC won't show.
IBM's compiler use a *strict* ANSI conforming scope, especially for static inline.
Peek at https://bugzilla.mozilla.org/show_bug.cgi?id=526422
or https://bugzilla.mozilla.org/show_bug.cgi?id=526436
or https://bugzilla.mozilla.org/show_bug.cgi?id=526450
and this one may be resolved similiarly.

If you intend to do a AIX port of 1.9.2 branch, I can set up a build host quite similiar to yours and will help you confirming the bugs and getting the patches checked into the branch after the needed reviews and approvals.

As dveditz wrote: from the official Mozilla side AIX is one below the lowest tiers of support. 
The Firefox 3.5 port was done by Shailen and me. Shailen focussing on 64bit, I did the 32bit build, the trivial backport to AIX 5.1 XLC/C++ 7.0.0.10 and review until ready to checkin stuff.
Likewise we wouldn't block the net release on a non-tier 1 platform.
blocking2.0: ? → -
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → ul.mcamafia
Blocks: 618660
To resolve the calls to static template functions in a different unit the calls must be fully qualified.
Else a trivial patch.
Attachment #497136 - Flags: review?(sdwilsh)
Status: NEW → ASSIGNED
Would a |using namespace mozilla::storage;| statement inside of variantToSQLiteT also work?
No, does not work.

backed out my local patch and added as suggested: 
"  using namespace mozilla::storage;" as first statement within 
template <typename T>
 int variantToSQLiteT(T aObj, nsIVariant *aValue)

and I got the very same error:

-DATK_MAJOR_VERSION=1 -DATK_MINOR_VERSION=12 -DATK_REV_VERSION=3  -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT /home/ulink/src/mozilla-1.9.2/storage/src/mozStorageConnection.cpp
"../../dist/include/mozilla/Mutex.h", line 66.27: 1540-0198 (W) The omitted keyword "private" is assumed for base class "BlockingResourceBase".
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 58.12: 1540-0274 (S) The name lookup for "sqlite3_T_null" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 58.12: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 51.1: 1540-0700 (I) The previous message was produced while processing "mozilla::storage::variantToSQLiteT<sqlite3_context *>(sqlite3_context *, nsIVariant *)".
"/home/ulink/src/mozilla-1.9.2/storage/src/mozStorageConnection.cpp", line 240.7: 1540-0700 (I) The previous message was produced while processing "mozilla::storage::<unnamed>::aggregateFunctionFinalHelper(sqlite3_context *)".
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 72.14: 1540-0274 (S) The name lookup for "sqlite3_T_int" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 72.14: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 82.14: 1540-0274 (S) The name lookup for "sqlite3_T_int64" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 82.14: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 90.14: 1540-0274 (S) The name lookup for "sqlite3_T_double" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 90.14: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 111.14: 1540-0274 (S) The name lookup for "sqlite3_T_text" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 111.14: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 125.14: 1540-0274 (S) The name lookup for "sqlite3_T_text16" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 125.14: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 151.16: 1540-0274 (S) The name lookup for "sqlite3_T_blob" did not find a declaration.
"/home/ulink/src/mozilla-1.9.2/storage/src/variantToSQLiteT_impl.h", line 151.16: 1540-1292 (I) Static declarations are not considered for a function call if the function is not qualified.
gmake[2]: *** [mozStorageConnection.o] Error 1
gmake[2]: Leaving directory `/home/ulink/src/mozilla-1.9.2/obj-aix53-opt/storage/src'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory `/home/ulink/src/mozilla-1.9.2/obj-aix53-opt/storage'
gmake: *** [default] Error 2

Tried also with a "using namespace" before the template. Same result.

seems using namespace does not override the hidden visibility due to a static for IBM XLC/C++.
Last thing I'd like you to try - remove the static bits, and wrap it in an anonymous namespace (also do the #include there maybe?).  I really don't want to add the mozilla::storage bits in front of ever call there.
Attached patch alternate patch, removing static (obsolete) — Splinter Review
This patch resolves the compilation error on AIX.
I preferred the fully qualified call for a porting hack instead, because it didn't changed the semantics at all without any runtime cost. 
But I agree: it looks ugly.
Here is the variant with removed "static", looking far less ugly.
Attachment #500189 - Flags: review?(sdwilsh)
https://bugzilla.mozilla.org/show_bug.cgi?id=526436#c1

contains the explaination of IBM's strict interpretation of the ANSI C++ standard,
and the template definition is in a different unit. It's a common bug when porting to AIX, as other compilers are more relaxed here.
Does wrapping all this in an anonymous namespace also work?  That lets us keep the safety of static, but without the fully qualified calls (if it works).
Comment on attachment 500189 [details] [diff] [review]
alternate patch, removing static

On second thought, I don't care.  r=sdwilsh
Attachment #500189 - Flags: review?(sdwilsh)
Attachment #500189 - Flags: review+
Attachment #500189 - Flags: approval2.0+
Attachment #497136 - Flags: review?(sdwilsh)
(In reply to comment #10)
> Does wrapping all this in an anonymous namespace also work?  That lets us keep
> the safety of static, but without the fully qualified calls (if it works).

Nope: the IBM XLC compiler needs a call of a static function always fully qualified if the call is from outside the actual template definitions translation unit. So it would read at least "::sqlite3_T_...".
It should be possible to duplicate the template into the to two affected .h files, so the template is then within the scope of translation unit. Only moving the #include from the .cpp to the .h does not help. I guess it was intentionally moved to a separate header to avoid such redundancy.

Seems IBM counts the term "translation unit" before preprocessor (or preprocessing until the first C++ statement is reached), and GCC after preprocessor.
applied the branch 1.9.2 patch to m-c and recreated with "hg diff -U 8 -p"
Attachment #497136 - Attachment is obsolete: true
Attachment #500189 - Flags: approval1.9.2.14?
Keywords: checkin-needed
Whiteboard: [attachment 500260 to m-c]
(In reply to comment #12)
> Nope: the IBM XLC compiler needs a call of a static function always fully
> qualified if the call is from outside the actual template definitions
> translation unit. So it would read at least "::sqlite3_T_...".
> It should be possible to duplicate the template into the to two affected .h
> files, so the template is then within the scope of translation unit. Only
> moving the #include from the .cpp to the .h does not help. I guess it was
> intentionally moved to a separate header to avoid such redundancy.
I should note that wrapping it in an anonymous namespace would allow us to drop the static keyword as well.  (in case I wasn't clear earlier)
moved the calls into the anonymus namespace and removed static.
Attachment #500189 - Attachment is obsolete: true
Attachment #500260 - Attachment is obsolete: true
Attachment #500374 - Flags: review?(sdwilsh)
Attachment #500189 - Flags: approval1.9.2.14?
Keywords: checkin-needed
Whiteboard: [attachment 500260 to m-c]
Attached patch same patch for 1.9.2 branch (obsolete) — Splinter Review
Context adjusted for branch 1.9.2
Attachment #500375 - Flags: review?(sdwilsh)
Comment on attachment 500374 [details] [diff] [review]
removed static, added to anonymus namespace, trunk/m-c patch

>+++ b/storage/src/mozStorageConnection.cpp	Thu Dec 30 13:21:41 2010 -0600
>@@ -79,84 +79,85 @@ PRLogModuleInfo* gStorageLog = nsnull;
> namespace mozilla {
> namespace storage {
> 
> #define PREF_TS_SYNCHRONOUS "toolkit.storage.synchronous"
> 
> ////////////////////////////////////////////////////////////////////////////////
> //// Variant Specialization Functions (variantToSQLiteT)
> 
>-static int
>+namespace {
nit: move this above the //// Variant... comment please

r=sdwilsh
Attachment #500374 - Flags: review?(sdwilsh) → review+
fixed nit, carrying forward r+
Attachment #500375 - Attachment is obsolete: true
Attachment #500375 - Flags: review?(sdwilsh)
patch adjusted for branch 1.9.2
Attachment #500380 - Flags: review?(sdwilsh)
Comment on attachment 500380 [details] [diff] [review]
same patch for 1.9.2 branch

r=sdwilsh
Attachment #500380 - Flags: review?(sdwilsh)
Attachment #500380 - Flags: review+
Attachment #500380 - Flags: approval1.9.2.14?
Attachment #500379 - Flags: review+
Attachment #500379 - Flags: approval2.0+
Comment on attachment 500380 [details] [diff] [review]
same patch for 1.9.2 branch

approved 1.9.2.14, a=dveditz for release-drivers
Attachment #500380 - Flags: approval1.9.2.14? → approval1.9.2.14+
Keywords: checkin-needed
Whiteboard: [attachment 500379 to trunk], [attachment 500380 to moz192]
Blocks: 623504
Whiteboard: [attachment 500379 to trunk], [attachment 500380 to moz192] → [attachment 500379 to trunk]
Keywords: verified1.9.2
http://hg.mozilla.org/mozilla-central/rev/d7930adbeb1a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [attachment 500379 to trunk]
Target Milestone: --- → mozilla2.0b10
You need to log in before you can comment on or make changes to this bug.