building with CTL support

[Jungshik Shin]

Has any one tried building Mozilla with CTL enabled
(enable-ctl) on Linux recently? While trying to fix bug 203052
(http://bugzilla.mozilla.org/show_bug.cgi?id=203052 : patch there doesn't
even get compiled. I have an updated patch), I was puzzled that none
of encoders defined in intl/ctl was available to me. ( cvtr. manager
failed.). I've just taken a look at the build log and found that the
link failed with a bunch of error messages as enclosed below:

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

U NS_CheckThreadSafe
U NS_CurrentThread
U _GLOBAL_OFFSET_TABLE_
......
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

My 'ld' is GNU ld version 2.13.90.0.2 20020802
and 'g++' is g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)


Any help/idea/hint would be great. TIA,

Jungshik


------ link command and error message -----------
c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer- arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -pedantic
-Wno-long-long -fshort-wchar -pthread -pipe -DDEBUG -D_DEBUG
-DDEBUG_jungshik -DTRACING -g -fno-inline -O -I/usr/include/glib-1.2
-I/usr/lib/glib/include -fPI C -shared -Wl,-h -Wl,libctl.so -o libctl.so
nsULE.o nsUnicodeToTIS620.o nsUnico deToSunIndic.o nsUnicodeToThaiTTF.o
nsCtlLEModule.o -Wl,-Bsymbolic
-L/usr/lib -rdynamic -lgmodule -lglib -ldl -L../../../dist/bin -lxpcom
-libert y -liberty -L../../../dist/bin -L/prj/moz/builds/lin/opt/dist/lib
-lplds4 -lplc4
-lnspr4 -lpthread -ldl -L../../../dist/lib -lxpcom_compat
-L../../../dist/lib -lmozpango -ldl -lm

nsULE.o: In function `nsULE::AddRef()':
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference to `nsDebug::PreCondition(char const*, char const*, char const*, int)'
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference to `NS_CheckThreadSafe'
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference to `nsTraceRefcnt::LogAddRef(void*, unsigned, char const*, unsigned)'
nsULE.o: In function `nsULE::Release()':
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference to `nsDebug::PreCondition(char const*, char const*, char const*, int)'
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference to `NS_CheckThreadSafe'
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference t
o `nsTraceRefcnt::LogRelease(void*, unsigned, char const*)'
nsULE.o: In function `nsULE::QueryInterface(nsID const&, void**)':
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:61: undefined
reference t
o `nsDebug::Assertion(char const*, char const*, char const*, int)'
nsULE.o: In function `nsULE::GetCtlData(unsigned short const*, unsigned,
_PangoliteGlyphString*, char const*)':
/mnt/photon/prj/moz/src/mozilla/intl/ctl/src/nsULE.cpp:186: undefined
reference to `nsMemory::Free(void*)'
nsULE.o: In function
`nsAutoOwningThread::nsAutoOwningThread[in-charge]()':
......

[Christopher Seawood]

Post by Jungshik Shin
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.

Post by Jungshik Shin
I ran 'nm' over nsULE.o (one of object files linked in) and obtained
U NS_CheckThreadSafe
U NS_CurrentThread
U _GLOBAL_OFFSET_TABLE_
......
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

Those symbols are not the same. They are mangled differently (ZN7 vs
ZN8, for starters). It looks like you're linking against a different
version of xpcom than those object files were compiled against. 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 .

- cls

[Jungshik Shin]

Post by Christopher Seawood

Post by Jungshik Shin
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.

Post by Christopher Seawood

Post by Jungshik Shin
I ran 'nm' over nsULE.o (one of object files linked in) and obtained
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.