340275 - Make nsTArray available to XULRunner apps

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Right now I get the following link errors when using nsTArray:

unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall nsTArray_base::Length(void)const " (__imp_?Length@nsTArray_base@@QBEIXZ)
unresolved external symbol "__declspec(dllimport) protected: __thiscall nsTArray_base::nsTArray_base(void)" (__imp_??0nsTArray_base@@IAE@XZ)
unresolved external symbol "__declspec(dllimport) protected: void __thiscall nsTArray_base::ShiftData(unsigned int,unsigned int,unsigned int,unsigned int)" (__imp_?ShiftData@nsTArray_base@@IAEXIIII@Z)
unresolved external symbol "__declspec(dllimport) protected: int __thiscall nsTArray_base::EnsureCapacity(unsigned int,unsigned int)" (__imp_?EnsureCapacity@nsTArray_base@@IAEHII@Z)
unresolved external symbol "__declspec(dllimport) protected: void __thiscall nsTArray_base::IncrementLength(unsigned int)" (__imp_?IncrementLength@nsTArray_base@@IAEXI@Z) referenced in function "public: int * __thiscall nsTArray<int>::AppendElements<int>(int const *,unsigned int)" (??$AppendElements@H@?$nsTArray@H@@QAEPAHPBHI@Z)

I'm linking xpcom.lib and xul.lib and MOZILLA_INTERNAL_API is defined. I'm not sure if this is an issue on the trunk.

Comment 1

[Darin Fisher]

Try linking to xpcomglue_s.lib in addition to xpcom.lib.  You shouldn't need to link to xul.lib.

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #1)
> Try linking to xpcomglue_s.lib in addition to xpcom.lib.  You shouldn't need to
> link to xul.lib.
> 
I'm using unfrozen interfaces so I hadn't tried xpcomglue_s.lib, but I still get the same unresolved externals (in addition to several others... is nsAutoLock not part of the glue?!?). Could I be missing some defines?

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

BTW, all Songbird's components are linked according to (which is why I have xul.lib linked in):

http://groups.google.com/group/netscape.public.dev.xul/tree/browse_frm/thread/f37ad3abf15b5a1c/c6e0e3301ce59d49?rnum=1&hl=en&q=xul.lib&_done=%2Fgroup%2Fnetscape.public.dev.xul%2Fbrowse_frm%2Fthread%2Ff37ad3abf15b5a1c%2Fc6e0e3301ce59d49%3Ftvc%3D1%26q%3Dxul.lib%26hl%3Den%26#doc_e3ec8f0d135f2b31

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

And I guess I should mention that this same code + linkage strategy worked fine when I was using nsVoidArray.

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Okay, at the advice of bsmedberg I added nsTArray to xpcom/build/dlldeps.cpp and things work properly now. Seems that MSVC was stripping those symbols from the libs because they weren't being used. Patch in a sec.

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch v1.0

Adds some nsTArray calls to dlldeps.cpp so that msvc won't strip nsTArray symbols from export libs.

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 224746 [details] [diff] [review]
patch v1.0

I always forget to request branch approval...

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

fixed on trunk and branch