Re: building with CTL support

Jungshik Shin <[email protected]> Fri, 25 Apr 2003 09:10:25 +0900
Newsgroups gmane.comp.mozilla.internationalization,gmane.comp.mozilla.builds
Organization Another Netscape Collabra Server User
Message-ID <[email protected]>
Christopher Seawood wrote:
> Jungshik Shin wrote:
> 
>> Has any one tried building Mozilla with CTL enabled
>> (enable-ctl) on Linux recently? 
> 
> 
> There are several tinderboxes on the Ports page which build with 
> --enable-ctl.

Thank you for your answer. I'll check them out.

>> I ran 'nm' over nsULE.o (one of object files linked in) and obtained
>> the following:
>>

>>          U _ZN7nsDebug12PreConditionEPKcS1_S1_i
>>          U _ZN7nsDebug9AssertionEPKcS1_S1_i
>>          U _ZN8nsMemory4FreeEPv
>>
>> However, libxpcom.so has apparently all of them. For instance, 'nm' on 
>> libxpcom.so gave me
>> 001292e4 T _ZN8nsMemory22GetGlobalMemoryServiceEv
>> 001291fa T _ZN8nsMemory4FreeEPv
>> 0012916c T _ZN8nsMemory5AllocEj

 > Make sure that you don't have a system version of xpcom installed and 
 > are pulling that version in before the in-tree version due to ld's
 > handling of -L

   Yes, that's what happened. I've got libxpcom.so in /usr/lib from 
Mozilla 1.0.x.  _both_ in-tree libxpcom.so(from which the above
output was obtained) and nsULE.o have _ZN8nsMemory4FreeEPv
[1] for nsMemory::Free while /usr/lib/libxpcom.so has Free__8nsMemoryPv.

It's strange that the only CTL module had that problem, though.

Thank you.

Jungshik

[1] I'm sorry it was confusing because I listed two different sets
of symbols for nsULE.o and in-tree libxpcom. nsMemory::Free was common
in two sets and they've got the same mangled name.