Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev kab...@gmail.com wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexander Kabaev wrote: On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev kab...@gmail.com wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. My amd64 system is a little out of date, but I'll give it a try. If it builds, I'll update to a recent -current and try rebuilding it. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote:
On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev
shuv...@physik.uni-wuerzburg.de wrote:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that
nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
ls /usr/local/lib/libiconv*so* ?
~ ll /usr/local/lib/libiconv*so*
lrwxr-xr-x 1 root wheel 13 Jan 27 13:14 /usr/local/lib/libiconv.so -
libiconv.so.3
-r--r--r-- 1 root wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3
I'm not so lame :)
On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote:
On Sat, 29 Jan 2011 13:21:44 -0500
Alexander Kabaev kab...@gmail.com wrote:
On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
Daniel Eischen deisc...@freebsd.org wrote:
On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month
now [1]. Examining build log and reproducing it locally, the
problem is in the usage of libiconv in nsNativeCharsetUtils.cpp.
The linker fails to produce libxpcom_core.so although
-L/usr/local/lib and -liconv are specified [2]. Examining this
further I found that nsNativeCharsetUtils.o produced with [3]
fails to link with libiconv alone too [4] (note still unresolved
libiconv references). I'm not a compiler/linker guru and do not
understand what is happening here. As a workaroud I use the
attached patch which disables the usage of libiconv in
nsNativeCharsetUtils.cpp.
Yes, I had this problem also on -current. Does seamonkey build
on recent 8.x?
libxpcomio_s.a is a static library that has unresolved references
to libiconv. I guess I'd expect those references to be resolved
with a later -L/usr/local/lib -liconv when building the shared
library (libxpcom_core.so), but they are not.
My wild guess: seamonkey tries to hide symbols that are coming from
different .o file (this time one from libiconv.a) and that fails with
our toolchain.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--
Alexander Kabaev
Follow-up to myself: Nope, the fix to said bug appears in our compiler.
Can you make amd64 version of nsNativeCharsetUtils.
--
Alexander Kabaev
??? (It is already on amd64)
Well, I have fogotten to put my environment:
~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed
Jan 26 17:00:37 CET 2011
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC amd64
And here is the winner:
On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
Alexey Shuvaev shuv...@physik.uni-wuerzburg.de writes:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that
nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
[...]
/usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
/head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
@${ECHO_CMD} #pragma GCC system_header ${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility push(default)
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #include \${LOCALBASE}/include/iconv.h\
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility pop ${MOZSRC}/${subdir}/iconv.h
%%
Index: www/seamonkey2/Makefile
===
RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
retrieving revision 1.315
diff -u -p -r1.315 Makefile
--- www/seamonkey2/Makefile 10 Dec 2010 13:31:12 - 1.315
+++ www/seamonkey2/Makefile 29 Jan 2011 05:22:11 -
@@ -28,11 +28,10 @@ ALL_TARGET= default
MAKE_JOBS_SAFE= yes
MOZ_PIS_SCRIPTS= moz_pis_S50cleanhome
MAKE_ENV=LD_LIBRARY_PATH=${WRKSRC}/dist/bin
-CONFIGURE_ENV=
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
And here is the winner:
On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
Alexey Shuvaev shuv...@physik.uni-wuerzburg.de writes:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
[...]
/usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
/head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
Is someone going to commit this?
@${ECHO_CMD} #pragma GCC system_header ${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility push(default)
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #include \${LOCALBASE}/include/iconv.h\
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility pop ${MOZSRC}/${subdir}/iconv.h
%%
Index: www/seamonkey2/Makefile
===
RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
retrieving revision 1.315
diff -u -p -r1.315 Makefile
--- www/seamonkey2/Makefile 10 Dec 2010 13:31:12 - 1.315
+++ www/seamonkey2/Makefile 29 Jan 2011 05:22:11 -
@@ -28,11 +28,10 @@ ALL_TARGET= default
MAKE_JOBS_SAFE=yes
MOZ_PIS_SCRIPTS= moz_pis_S50cleanhome
MAKE_ENV= LD_LIBRARY_PATH=${WRKSRC}/dist/bin
-CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include/cairo
+CONFIGURE_ENV= LOCALBASE=${LOCALBASE} CPPFLAGS=-I${LOCALBASE}/include/cairo \
+ ac_cv_func__Unwind_Backtrace=no
USE_GCC= 4.2+
-CONFIGURE_ENV= LOCALBASE=${LOCALBASE}
-
MOZ_EXTENSIONS=default
MOZ_OPTIONS+= --with-default-mozilla-five-home=${PREFIX}/lib/${MOZILLA} \
--enable-svg \
@@ -121,11 +120,6 @@ post-patch:
${WRKSRC}/mozilla/storage/build/Makefile.in
@${REINPLACE_CMD} -e
'/accessibility.typeaheadfind.enablesound/s/true/false/' \
${WRKSRC}/mozilla/modules/libpref/src/init/all.js
- @${REINPLACE_CMD} -e 's|iconv.h|\${LOCALBASE}/include/iconv.h\|g' \
- ${WRKSRC}/configure \
- ${WRKSRC}/mozilla/configure \
- ${WRKSRC}/mozilla/intl/uconv/native/nsNativeUConvService.cpp \
- ${WRKSRC}/mozilla/xpcom/io/nsNativeCharsetUtils.cpp
@${REINPLACE_CMD} -e 's|libgnome-2.so.0|libgnome-2.so|' \
${WRKSRC}/mozilla/toolkit/xre/nsNativeAppSupportUnix.cpp \
${WRKSRC}/mozilla/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp
%%
This patch did it!
I have successfully rebuilt www/seamonkey2 with the above patch
applied to port's Makefile (and without my previous workaround).
Everything works!
As this hidden/visibility symbols are beyond my C/CPP foo,
I am leaving the final decision for the experts :)
Thanks,
Alexey.
___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
DE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 21:20:12 +0100 Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote: On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that ..o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. ls /usr/local/lib/libiconv*so* ? ~ ll /usr/local/lib/libiconv*so* lrwxr-xr-x 1 root wheel 13 Jan 27 13:14 /usr/local/lib/libiconv.so - libiconv.so.3 -r--r--r-- 1 root wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3 I'm not so lame :) On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote: On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev kab...@gmail.com wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. -- Alexander Kabaev ??? (It is already on amd64) Email was sent while not finished. Can you make amd64 version of nsNativeCharsetUtils.o available from somewhere along with corresponding .ii file? To get .ii file you can add -save-temps to GCC invocation used to compile nsNativeCharsetUtils.cpp. -- Alexander Kabaev signature.asc Description: PGP signature
[WORKAROUND] www/seamonkey2 on CURRENT
Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. My little more than 0.02$, Alexey. [1]: http://portsmon.freebsd.org/portoverview.py?category=wwwportname=seamonkey2wildcard= [2]: c++ -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 -pipe -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsArrayEnumerator.o nsArrayUtils.o nsCategoryCache.o nsCOMPtr.o nsCOMArray.o nsCRTGlue.o nsComponentManagerUtils.o nsEnumeratorUtils.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsISupportsImpl.o nsMemory.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsQuickSort.o nsVoidArray.o nsTArray.o nsThreadUtils.o nsTObserverArray.o nsCycleCollectionParticipant.o nsDeque.o nsAutoLock.o nsGenericFactory.o nsProxyRelease.o nsTextFormatter.o nsXPComInit.o nsXPCOMStrings.o -pthread -L/usr/local/lib/nss -Wl,-rpath,/usr/local/lib/seamonkey -lc -Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/comm-1.9.1/mozilla/dist/bin -Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/fake/lib -Wl,--whole-archive ../ds/libxpcomds_s.a ../io/libxpcomio_s.a ../components/libxpcomcomponents_s.a ../threads/libxpcomthreads_s.a ../proxy/src/libxpcomproxy_s.a ../base/libxpcombase_s.a ../reflect/xptcall/src/libxptcall.a ../reflect/xptcall/src/libxptcmd.a ../reflect/xptinfo/src/libxptinfo.a ../../dist/lib/libxpt.a ../string/src/libstring_s.a -Wl,--no-whole-archive -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread -pthread -L/usr/local/lib -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgio-2.0 -lXfixes -lgobject-2.0 -lgmodule-2.0 -lpng -lz -lm -lgthread-2.0 -lglib-2.0 -lcairo -lX11 -lm -pthread -lm -pthread -pthread -L/usr/local/lib -liconv ../io/libxpcomio_s.a(nsNativeCharsetUtils.o)(.text+0x32): In function `xp_iconv(void*, char const**, unsigned int*, char**, unsigned int*)': : undefined reference to `libiconv' [3]: c++ -o nsNativeCharsetUtils.o -c -I../../dist/include/system_wrappers -include ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DMOZ_SUITE=1 -DOSTYPE=\FreeBSD9\ -DOSARCH=FreeBSD -D_IMPL_NS_COM -I.. -I. -I. -I../../dist/include/string -I../../dist/include -I../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 -pipe -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -Os -fno-strict-aliasing -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h nsNativeCharsetUtils.cpp [4]: c++ -o aaa nsNativeCharsetUtils.o -L/usr/local/lib -liconv /usr/lib/crt1.o(.text+0x8a): In function `_start': : undefined reference to `main' nsNativeCharsetUtils.o(.text+0x16): In function `xp_iconv(void*, char const**, unsigned long*, char**, unsigned long*)': : undefined reference to `libiconv' nsNativeCharsetUtils.o(.text+0x571): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `PR_DestroyLock' nsNativeCharsetUtils.o(.text+0x58e): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x5ab): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x5c8): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x5e5): In function `nsNativeCharsetConverter::GlobalShutdown()': : undefined reference to `libiconv_close' nsNativeCharsetUtils.o(.text+0x602): In function `nsNativeCharsetConverter::GlobalShutdown()': :
