537594 - AIX port unresolved external symbol, nsAutoSyncManager.cpp

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Uli Link (:ul-mcamafia)]

User-Agent:       Mozilla/5.0 (X11; U; AIX 5.1; en-US; rv:1.9.1.6) Gecko/20100101 SeaMonkey/2.0.1
Build Identifier: Thunderbird 3.0.x / Seamonkey 2.0.x

rm -f libmail.so
xlC_r -qmkshrobj=1 -o libmail.so -bE:/home/ulink/Src/comm-1.9.1/mozilla/build/unix/aix.exp -bnoexpall  nsMailModule.o     -lpthreads -bh:5 -Wl,-brtl -blibpath:/usr/lib:/lib     ../base/util/libmsgbsutl_s.a ../base/src/libmsgbase_s.a ../base/search/src/libmsgsearch_s.a ../local/src//libmsglocal_s.a ../compose/src/libmsgcompose_s.a ../db/msgdb/src/libmsgdb_s.a ../imap/src/libmsgimap_s.a ../addrbook/src/libaddrbook_s.a ../news/src/libmsgnews_s.a ../mime/src/libmime_s.a ../mime/emitters/src/libemitterutil_s.a ../extensions/bayesian-spam-filter/src/libbayesflt_s.a ../extensions/fts3/src/libfts3tok_s.a ../extensions/mailviews/src/libmailview_s.a ../extensions/mdn/src/libmsgmdn_s.a ../mime/cthandlers/vcard/libvcard_s.a ../mime/cthandlers/glue/libmimecthglue_s.a   ../../mozilla/rdf/util/src/internal/librdfutil_s.a ../../mozilla/modules/libreg/src/libmozreg_s.a -L/home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist/bin -lmozjs /home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist/lib/libunicharutil_s.a -L/home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist/bin -lxpcom -lxpcom_core  -liconv -L/home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist/bin `/home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist/bin/nspr-config --prefix=/home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist --libdir=/home/ulink/Src/comm-1.9.1/TB3_OBJ/mozilla/dist/lib --libs` -lz    -lC_r -ldl -lm -lc_r    
ld: 0711-317 ERROR: Undefined symbol: nsAutoSyncManager::kDefaultGroupSize
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
gmake[4]: *** [libmail.so] Error 8
gmake[4]: Leaving directory `/home/ulink/Src/comm-1.9.1/TB3_OBJ/mailnews/build'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory `/home/ulink/Src/comm-1.9.1/TB3_OBJ/mailnews'
gmake[2]: *** [libs_tier_app] Error 2
gmake[2]: Leaving directory `/home/ulink/Src/comm-1.9.1/TB3_OBJ'
gmake[1]: *** [tier_app] Error 2
gmake[1]: Leaving directory `/home/ulink/Src/comm-1.9.1/TB3_OBJ'
gmake: *** [default] Error 2


Reproducible: Always

Steps to Reproduce:
1. Compile on AIX 5.1 with IBM XLC/C++ 7.0

Actual Results:  
Linker error when binding libmail.so

Expected Results:  
Successfull compilation, linking and a resulting stable binary

Comment 1

[Uli Link (:ul-mcamafia)]

Attachment: additional const cast to avoid symbol from not being exported

This resolves the linking error.

Comment 2

[Ludovic Hirlimann [:Usul]]

(In reply to comment #1)
> Created an attachment (id=419821) [details]
> additional const cast to avoid symbol from not being exported
> 
> This resolves the linking error.

You need to ask for review and sr as described at https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements.

Comment 3

[Uli Link (:ul-mcamafia)]

The IBM XLC/C++ compilers are very picky about the constness of array size.

Comment 4

[David :Bienvenu]

But kDefaultGroupSize is already const. Would moving it out of the header file into the cpp file fix the error as well? It doesn't need to be declared in the class at all.

Comment 5

[Uli Link (:ul-mcamafia)]

(In reply to comment #4)
> But kDefaultGroupSize is already const. 

Yes. 
I don't understand why, but the patch makes libmail.so link successfully on AIX and mGroupSize is initialized with 60K. 
When I need porting changes I prefer minimal (or none?) impact first.

> Would moving it out of the header file
> into the cpp file fix the error as well? It doesn't need to be declared in the
> class at all.

Will try this later. Will be quite time consuming as I have to test it with both SeaMonkey and Thunderbird.

Comment 6

[Uli Link (:ul-mcamafia)]

https://bugzilla.mozilla.org/show_bug.cgi?id=429105#c3

Comment 7

[Uli Link (:ul-mcamafia)]

Attachment: additional const cast keeps visibility of kDefaultGroupSize

Comment 8

[David :Bienvenu]

I don't want kDefaultGroupSize to be visible - there's no need for it, so it's better for it not to be visible. So moving the declaration would be improving the code, as well as fixing the compiler error.

Comment 9

[Uli Link (:ul-mcamafia)]

Comment on attachment 425806 [details] [diff] [review]
additional const cast keeps visibility of kDefaultGroupSize 

I can add a comment that the const cast is needed to workaround the IBM VisualAge Compiler.

Comment 10

[David :Bienvenu]

(In reply to comment #9)
> (From update of attachment 425806 [details] [diff] [review])
> I can add a comment that the const cast is needed to workaround the IBM
> VisualAge Compiler.

I'd still rather see the declaration moved to be more private, with less scope. And those kinds of comments always decrease my faith in the compiler :-)

Comment 11

[Uli Link (:ul-mcamafia)]

Attachment: w/o additional const casts

Proposal No. 1

Comment 12

[Uli Link (:ul-mcamafia)]

Attachment: resolves the linker error

Moved static const member kDefaultGroupSize from header to .cpp else the linker cannot resolve kDefaultGroupSize within SetGroupSize member function's ? : operator.

Comment 13

[David :Bienvenu]

Comment on attachment 425832 [details] [diff] [review]
resolves the linker error

fix checked in, thx, Uli.

Comment 14

[David :Bienvenu]

fixed on the trunk, that is. I'm guessing you'd like this for the 3.0x branch as well?

Comment 15

[David :Bienvenu]

Comment on attachment 425832 [details] [diff] [review]
resolves the linker error

I'll land this for 3.0x as well, tomorrow, if I don't forget...

Comment 16

[Mark Banner (:standard8)]

Checked into comm-1.9.1:
http://hg.mozilla.org/releases/comm-1.9.1/rev/9f833ebcf0bf

Comment 17

[Mark Banner (:standard8)]

Verified fixed by code inspection (simple move of variable) and the fact that the tree still builds etc.

Comment 18

[Uli Link (:ul-mcamafia)]

(In reply to comment #17)
> Verified fixed by code inspection (simple move of variable) and the fact that
> the tree still builds etc.

And builds fine on AIX verified yesterday with a "nightly" build just before the 3.0.2 RELEASE version bump.