Closed Bug 202747 Opened 23 years ago Closed 13 years ago

nsNativeCharsetUtils.cpp doesn't work on Tru64

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
DEC
OSF/1
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: masaki.katakai, Assigned: smontagu)

Details

Attachments

(1 file)

a new test program (for iconv)
1.14 KB, patch
Details | Diff | Splinter Review
According to bug 196062, nsNativeCharsetUtils.cpp does not work on Tru64. ###!!! ASSERTION: no native to utf-8 converter: 'gNativeToUTF8 != INVALID_ICONV_T', file nsNativeCharsetUtils.cpp, line 275 Break: at file nsNativeCharsetUtils.cpp, line 275 ###!!! ASSERTION: no utf-8 to native converter: 'gUTF8ToNative != INVALID_ICONV_T', file nsNativeCharsetUtils.cpp, line 282 Break: at file nsNativeCharsetUtils.cpp, line 282 configure sets the flag as below, but it seems that iconv() does not work on True64. -DHAVE_ICONV=1 -DHAVE_NL_TYPES_H=1 -DHAVE_NL_LANGINFO=1
In bugzilla-jp, N.Hayashi-san has verified this problem can be fixed by using #define USE_STDCONV 1 http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3131 Can we just put #ifdef OSF1 to nsNativeCharsetUtils.cpp? Is this right solution?
This is odd. I have a remote access to Tru64 v5 machine and it does have a working iconv(3). It'd be nice if attachment 125288 [details] to bug 208809 and attachment 125485 [details] to bug 209048 could be tried. See also bug 206811. According to HP/Compaq document, Tru64 V4 (OSF/1 V4?) also has iconv(3). I guess what's happening is that iconv(3) in Tru64 comes in modules and the necessary modules are not installed.
perhaps we should just disable UTF-8 fallback support? can someone try undefining ENABLE_UTF8_FALLBACK_SUPPORT? thanks!
actually, please ignore my comment about ENABLE_UTF8_FALLBACK_SUPPORT. disabling that would have no effect :-( what does nl_langinfo(CODESET) return?
Yeah, I also like to know what nl_langinfo(CODESET) returns. In addition, it'd be nice to run attachment 125288 [details] with "ISO-8859-1" replaced by nl_langinfo(CODESET) (of course, setlocale(LC_ALL, "") should be called before that.) BTW, it's interesting that at first I thought the same way as Darin (i.e. let's undefine UTF8_FALLBACK for Tru64). As we know now, it'd not help :-)
BTW, we can't use STDCONV reliably on Tru64 because wchar_t on Tru64 is locale-dependent. See http://h30097.www3.hp.com/unix/i18n.htm
Hi, I have reported the very same bug on Tru64 unix, I have GNU gettext installed from which I believe libiconv.a came. Look for my bugreport too.
*** Bug 197051 has been marked as a duplicate of this bug. ***
bug 197051 comment #0 is enlightening, but I'm not sure that bug is dupe of this one. The cause of bug 197051 is that the return value of nl_langinfo() is not recognized by GNU libliconv. Without GNU libiconv() installed(i.e. with native iconv(3) on Tru64), I guess there'd be no problem. Is this bug also about the problem arising from the charset name mismatch between nl_langinfo(CODESET) and GNU libiconv? reporter, please reply to my and darin's questions in comment #4 and comment #5. Without your answer, I can't proceed here. In addition, did you install GNU libiconv?
jshin: feel free to reopen that bug... I marked it duplicate based on same os & same problem description
I need more info. from the reporter of this bug to determine whether or not to reopen that bug.
Hi, I'm sorry for the delay in my response, I don't know how did it happen ... Right now I cannot log into the machine where I compiled mozilla, but have tried on another Tru64Unix 5.1A box. I went and installed as user GNU libiconv-1.9.1 and gettext-0.12.1. When libiconv is installed without libintl being from during it's configure process, I get from configure: configure:19823: checking how to link with libiconv configure:19825: result: -liconv configure:19836: checking for iconv declaration configure:19871: cc -c -g conftest.c >&5 configure:19874: $? = 0 configure:19877: test -s conftest.o configure:19880: $? = 0 configure:19895: result: extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); I had to use -liconv and -liconv_plug (both from GNU libiconv) to get the testfiel linked. I'm sure on the system for which I reported the bug, GNU gettext is installed ... and I believe GNU gettext installs GNU libiconv too. mmokrejs@prfdec$ cc a.c -L/usr/home3/mmokrejs/gnu/lib -liconv -liconv_plug cc: Warning: a.c, line 17: In this statement, performing pointer arithmetic on a pointer to void or a pointer to function is not allowed. The compiler will treat the type as if it were pointer to char. (badptrarith) exit -1; --------^ cc: Warning: a.c, line 23: In this statement, performing pointer arithmetic on a pointer to void or a pointer to function is not allowed. The compiler will treat the type as if it were pointer to char. (badptrarith) exit -2; --------^ mmokrejs@prfdec$ ./a.out 242765:./a.out: /sbin/loader: Fatal Error: Cannot map library libiconv.so.2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out 238445:./a.out: /sbin/loader: Fatal Error: Cannot map library libiconv_plug_osf.so mmokrejs@prfdec$ ls /usr/home3/mmokrejs/gnu/lib/libiconv* /usr/home3/mmokrejs/gnu/lib/libiconv.a /usr/home3/mmokrejs/gnu/lib/libiconv.so.2 /usr/home3/mmokrejs/gnu/lib/libiconv.la /usr/home3/mmokrejs/gnu/lib/libiconv.so.4.2.0 /usr/home3/mmokrejs/gnu/lib/libiconv.so /usr/home3/mmokrejs/gnu/lib/libiconv_plug.so mmokrejs@prfdec$ find libiconv-1.9.1 -name libiconv_plug_osf.so libiconv-1.9.1/lib/libiconv_plug_osf.so mmokrejs@prfdec$ ls -la libiconv-1.9.1/lib/libiconv_plug_osf.so -rw------- 1 mmokrejs users 1751008 Nov 15 20:51 libiconv-1.9.1/lib/libiconv_plug_osf.so mmokrejs@prfdec$ ls -la /usr/home3/mmokrejs/gnu/lib/libiconv_plug.so -rw-r--r-- 1 mmokrejs users 1751008 Nov 15 20:51 /usr/home3/mmokrejs/gnu/lib/libiconv_plug.so mmokrejs@prfdec$ pushd /usr/home3/mmokrejs/gnu/lib/ ~/gnu/lib ~ mmokrejs@prfdec$ ln -s libiconv_plug.so libiconv_plug_osf.so mmokrejs@prfdec$ popd ~ mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out Usage: iconv_test (UTF-16|UTF-16LE|UTF-16BE) Segmentation fault (core dumped) mmokrejs@prfdec$ mmokrejs@prfdec$ dbx ./a.out ./core dbx version 5.1 Type 'help' for help. Core file created by program "a.out" signal Segmentation fault at [iconv_open:224 +0x400efe30,0x300000e3240] Source not available (dbx) where > 0 iconv_open(tocode = (nil), fromcode = 0x140000040 = "ISO-8859-1") ["./iconv.c":224, 0x300000e3240] 1 main(argc = (unallocated - symbol optimized away), argv = (unallocated - symbol optimized away)) ["a.c":20, 0x120001470] (dbx) quit mmokrejs@prfdec$ echo $LC_ALL mmokrejs@prfdec$ echo $LANG mmokrejs@prfdec$ Does that help you? BTW: You can make yourself free account on Tru64machine on http://testdrive.hp.com
OK, maybe I got what you wanted me to do: ;) mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-1 out[0]= 20, outlen=3 out[0]= 20, outlen=3 mmokrejs@prfdec$
Thanks. What I meant is that you need to replace 'ISO-8859-1' in the source code with nl_langinfo(CODESET) before compiling it. I made that change ann am uploading it now. It'd be nice if you try this with the command line argument of 'UTF-16', 'UTF-16LE', 'UTF-16BE' and 'UCS-2' I've used HP testdrive, but unfortunately, those machines don't have any iconv module other than ISO-8859-1 so that it doesn't help me much except that I figure out the return value of nl_langinfo(CODESET) in POSIX locale in Tru64 v5.1a. It's ISO8859-1. 'ISO8859-1' is recognized by GNU libiconv so that I don't know what's wrong. Anyway, let me make sure I understand your test environment. On both machines you found this bug, you have GNU libiconv installed and it's linked (at run-time via LD_LIBRARY_PATH) instead of Tru64's native iconv. Is there any reason you installed GNU libiconv? According to HP/Compaq document, Tru64 5.x has a rather good implementation of iconv(3). Perhaps, it's not installed by default, but you may persuade your system admin to install at least UTF-8, UTF-16(LE|BE) modules in addition to ISO-8859-1 module.
Hi, I tried your updated test program. I installed GNU gettext/libiconv as some program seemed to require it and I thought it does not harm and is more tested. So, I have not much clue if I really need it. ;( I believe the machines have installed several locales. On the machine I have access right now(not the one used to report original bug) has the following behaviour: mmokrejs@prfdec$ cc -g3 a.c -L/usr/home3/mmokrejs/gnu/lib -liconv -liconv_plug mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16 codeset = ISO8859-1 out[0]=fffe, outlen=0 out[0]=2000, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16LE codeset = ISO8859-1 out[0]= 20, outlen=2 out[0]= 20, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16BE codeset = ISO8859-1 out[0]=2000, outlen=2 out[0]=2000, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UCS-2 codeset = ISO8859-1 out[0]=2000, outlen=2 out[0]=2000, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-2 codeset = ISO8859-1 out[0]=c720, outlen=3 out[0]=c720, outlen=3 mmokrejs@prfdec$ mmokrejs@prfdec$ grep -i locale inst OSFEURLOC520 installed Single-Byte European Locales (System Administration) mmokrejs@prfdec$ mmokrejs@prfdec$ LC_ALL="cs_CZ" mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-2 codeset = ISO8859-1 out[0]=8a20, outlen=3 out[0]=8a20, outlen=3 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UCS-2 codeset = ISO8859-1 out[0]=2000, outlen=2 out[0]=2000, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16BE codeset = ISO8859-1 out[0]=2000, outlen=2 out[0]=2000, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16LE codeset = ISO8859-1 out[0]= 20, outlen=2 out[0]= 20, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16 codeset = ISO8859-1 out[0]=fffe, outlen=0 out[0]=2000, outlen=2 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-2 codeset = ISO8859-1 out[0]=8f20, outlen=3 out[0]=8f20, outlen=3 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-2 codeset = ISO8859-1 out[0]=d920, outlen=3 out[0]=d920, outlen=3 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-2 codeset = ISO8859-1 out[0]=f320, outlen=3 out[0]=f320, outlen=3 mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out ISO-8859-2 codeset = ISO8859-1 out[0]=f120, outlen=3 out[0]=f120, outlen=3 mmokrejs@prfdec$ I don't know why the output changes, but hope you know why. I'm not sure but it seemed to me that GNU libiconv is using iconv(3) from system anyway ... I have this impression because of the test done by libiconv-1.9.1/configure (in comment #12).
Regarding your question in comment #14, iconv(3) from system is in libc: mmokrejs@prfdec$ strings /usr/shlib/libc.so | grep iconv iconv_close iconv iconv_open /usr/shlib/libiconv.so mmokrejs@prfdec$ So, I use LD_LIBRARY_PATH to help loader to find -liconv, which originates only from GNU libiconv(I had a look into gettext distribution and there's not libiconv packaged, to clarify my comment #12 about gettext installing also libiconv).
Hmm, but there is /usr/shlib/libiconv.so from vendor. :( mmokrejs@prfdec$ strings /usr/shlib/libiconv.so | grep iconv /iconv/iconv.alias /iconvTable/ /iconv/ /iconv/ mmokrejs@prfdec$ mmokrejs@prfdec$ nm -A /usr/shlib/libc.so | grep iconv mmokrejs@prfdec$ mmokrejs@prfdec$ nm -A /usr/shlib/libc.so | grep iconv [cut] /usr/shlib/libiconv.so: _iconv_ct_ett | 0004396974869168 | R | 0000000000000000 /usr/shlib/libiconv.so: _iconv_fold7_ett | 0004396974869744 | R | 0000000000000000 /usr/shlib/libiconv.so: _iconv_fold8_ett | 0004396974870320 | R | 0000000000000000 /usr/shlib/libiconv.so: close | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: fgets | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: fopen | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: free | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: getenv | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: iconv | 0004395907441904 | T | 0000000000000008 /usr/shlib/libiconv.so: iconv_close | 0004395907442096 | T | 0000000000000008 /usr/shlib/libiconv.so: iconv_open | 0004395907441824 | T | 0000000000000008 /usr/shlib/libiconv.so: isspace | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: malloc | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: open | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: putenv | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: read | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: strcasecmp | 0000000000000000 | U | 0000000000000008 /usr/shlib/libiconv.so: strcat | 0000000000000000 | U | 0000000000000008 So, I was wrong, there is -liconv also distributed by the system. Sorry for the spam. :( SO, here is the testcase using /usr/shlib/libiconv.so from the vendor: mmokrejs@prfdec$ cc -g3 a.c -liconv mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UCS-2 codeset = ISO8859-1 iconv_open failed mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16BE codeset = ISO8859-1 iconv_open failed mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16LE codeset = ISO8859-1 iconv_open failed mmokrejs@prfdec$ LD_LIBRARY_PATH=/usr/home3/mmokrejs/gnu/lib:$LD_LIBRARY_PATH ./a.out UTF-16 codeset = ISO8859-1 iconv_open failed mmokrejs@prfdec$ ldd ./a.out Main => ./a.out libiconv.so => /usr/shlib/libiconv.so libc.so => /usr/shlib/libc.so mmokrejs@prfdec$
Thanks a lot for your thorough testing. I logged onto HP/Compaq testdrive and build GNU libiconv, but somehow my test program always looks for libgcc_*so (which I don't have). Anyway, according to your test result, GNU libiconv works perfectly well (don't worry about the random first byte when you specify ISO-8859-2 in the command line because that first byte - actually the second byte because I'm casting char* to short* before printing- is 'undefined'. In both ISO-8859-1 and ISO-8859-2, 0x20 is 0x20 :-). As for the system libiconv, that's what I expected. Your system admin. didn't install anything other than the minimal iconv 'modules'. Among other things, UTF-8/UTF-16 modules are not installed on your system. Could you ask your system admin. to install UTF-8/UTF-16 modules on your system? AFAIK, Tru64 v4 and v5 installation CDs come with all the files necessary for all the locales supported by Tru64 (no addtional charge). Now back to GNU libiconv, I'm kinda at loss as to why Mozilla is failing even with GNU libiconv present. Maybe because it's picking up iconv(3) from the system libiconv instead of GNU libiconv. In addition to LD_LIBRARY_PATH setting, you may play with setting the env. variable _R???? (Bruno mentioned something about _R*.... in README file of GNU libiconv.).
The env. variable _R???? is to shadow iconv(3) coming from the system libiconv. It's just like LD_PRELOAD on Linux, Solaris, etc. (apparently, putting the path of GNU libiconv at the beginning of LD_LIBRARY_PATH is not sufficient....0
Using the _RLD_LIST variable does not help. BTW: The more usual trick with setting LD_LIBRARY_PATH should be equal. I tried eve LD_PRELOAD but all of themm give me same result: addax.gsf.de# export _RLD_LIST=/software/@sys/usr/lib/libiconv_plug.so:DEFAULT addax.gsf.de# hash -r addax.gsf.de# mozilla Type Manifest File: /afs/.gsf.de/alpha_dux51/usr/mozilla-1.6a-20031105/lib/mozilla-1.6a/components/xpti.dat +++ JavaScript debugging hooks installed. nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded nNCL: registering deferred (0) WARNING: Error parsing GRE default preferences. Is this an old-style embedding app?, file nsPrefService.cpp, line 757 ###!!! ASSERTION: no native to utf-8 converter: 'gNativeToUTF8 != INVALID_ICONV_T', file nsNativeCharsetUtils.cpp, line 313 Break: at file nsNativeCharsetUtils.cpp, line 313 ###!!! ASSERTION: no utf-8 to native converter: 'gUTF8ToNative != INVALID_ICONV_T', file nsNativeCharsetUtils.cpp, line 320 Break: at file nsNativeCharsetUtils.cpp, line 320 Using trace during execution, I see: open ("/usr/shlib/libXC.so", O_RDONLY, 0666) = -1 (No such file or directory) open ("/usr/lib/X11/locale/locale.alias", O_RDONLY, 0666) = 5 unknown_call () = 0 obreak (0x1400522a0) = 0 ioctl (5, 0x2000745e<Void,TIOCunknown,0>, 0) = -1 (Not a typewriter) read (5, 0x40042808, 8192) = 8192 [, "#\t$XConsortium: locale.alias /main/21 19"..., ] read (5, 0x40042808, 8192) = 874 [, "ucJP\nkorean\t\tko_KR.eucKR\nlithuanian\tlt_L"..., ] read (5, 0x40042808, 8192) = 0 [, "", ] close (5) = 0 open ("/usr/lib/X11/locale/locale.dir", O_RDONLY, 0666) = 5 unknown_call () = 0 ioctl (5, 0x2000745e<Void,TIOCunknown,0>, 0) = -1 (Not a typewriter) read (5, 0x40042808, 8192) = 4377 [, "#\t$XConsortium: locale.dir /main/7 1996/"..., ] lseek (5, -4143, SEEK_CUR) = 234 close (5) = 0 access ("/usr/lib/X11/locale/XLC_LOCALE/iso8859-1", 04) = 0 open ("/usr/lib/X11/locale/XLC_LOCALE/iso8859-1", O_RDONLY, 0666) = 5 unknown_call () = 0 ioctl (5, 0x2000745e<Void,TIOCunknown,0>, 0) = -1 (Not a typewriter) read (5, 0x40042808, 8192) = 800 [, "# $XConsortium: iso8859-1 /main/7 1996/"..., ] read (5, 0x40042808, 8192) = 0 [, "", ] I'm not sure this is related to the bug at all, but am just thinking about that lib libXC.so(although not present). Here's what is installed: addax.gsf.de# ls /usr/lib/X11/locale/XLC_LOCALE cp850 iso8859-2 iso8859-6 ja_JP.SJIS ja_JP.sdeckanji zh_CN.GB18030 zh_TW.UTF-8 en_US.UTF-8 iso8859-3 iso8859-7 ja_JP.UTF-8 ko_KR zh_CN.GBK zh_TW.big5 iso8859-1 iso8859-4 iso8859-8 ja_JP.deckanji ko_KR.UTF-8 zh_CN.UTF-8 zh_TW.dechanyu iso8859-15 iso8859-5 iso8859-9 ja_JP.eucJP th_TH.TACTIS zh_CN.dechanzi zh_TW.eucTW addax.gsf.de# addax.gsf.de# ldd /afs/.gsf.de/alpha_dux51/usr/mozilla-1.6a-20031105/lib/mozilla-1.6a/mozilla-bin libX11.so => /usr/shlib/libX11.so libpthreads.so => /usr/shlib/libpthreads.so libglib-1.2.so => /software/@sys/usr/lib/libglib-1.2.so libiconv.so => /software/@sys/usr/lib/libiconv.so libexc.so => /usr/shlib/libexc.so libc.so => /usr/shlib/libc.so libgtk-1.2.so => /software/@sys/usr/lib/libgtk-1.2.so librt.so => /usr/shlib/librt.so libplds4.so => /afs/.gsf.de/alpha_dux51/usr/mozilla-1.6a-20031105/lib/mozilla-1.6a/libplds4.so libdnet_stub.so => /usr/shlib/libdnet_stub.so libpthread.so => /usr/shlib/libpthread.so libXext.so => /usr/shlib/libXext.so libgmodule-1.2.so => /software/@sys/usr/lib/libgmodule-1.2.so libm.so => /usr/shlib/libm.so libmozjs.so => /afs/.gsf.de/alpha_dux51/usr/mozilla-1.6a-20031105/lib/mozilla-1.6a/libmozjs.so libplc4.so => /afs/.gsf.de/alpha_dux51/usr/mozilla-1.6a-20031105/lib/mozilla-1.6a/libplc4.so libcxx.so => /usr/lib/cmplrs/cxx/libcxx.so libgdk-1.2.so => /software/@sys/usr/lib/libgdk-1.2.so libintl.so.2 => /software/@sys/usr/lib/libintl.so.2 libnspr4.so => /afs/.gsf.de/alpha_dux51/usr/mozilla-1.6a-20031105/lib/mozilla-1.6a/libnspr4.so addax.gsf.de# The only explanation I have is that libc is used before libiconv and therefore symbols override.
Isn't this test broken in mozila/configure? I use cc/cxx but iconv() should have been found in /software/@sys/usr/lib/libiconv.a. I think -L flags should be before -liconv and other libs, right? But that's not the real problem I believe. configure:9278: checking for iconv in -liconv configure:9300: cxx -o conftest -O0 -arch ev56 -g2 -noexceptions -ieee -ptr $(DIST)/cxx_repository -pthread -I/software/@sys/usr/freety pe-2.1.4rc1/include -I/software/@sys/usr/include -I/usr/local2/include -I/usr/local/include -I/usr/local2/openssl/include -I/software/@s ys/usr/freetype-2.1.4rc1/include conftest.C -liconv -lm -lc_r -L/software/@sys/usr/lib -L/usr/local2/lib -L/usr/local/lib -L/usr/loca l2/openssl/lib -L/software/@sys/usr/freetype-2.1.4rc1/lib 1>&5 ld: Unresolved: iconv configure: failed program was: #line 9286 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char iconv(); int main() { iconv() ; return 0; }
> export _RLD_LIST=/software/@sys/usr/lib/libiconv_plug.so:DEFAULT The path of GNU libiconv on your another machine that you couldn't access before is the above, right? (I though it's in your home directory, but that's on a different machine). So overriding system iconv() (when running a precompiled binary) doesn't work.. Perhaps, I'll write Bruno, or will you? As for configuration/compilation issue, it should be a separate bug. Why don't you file one? Let's forget about GNU libiconv for the moment. The discussion on getting a precompiled Mozilla to run with GNU libiconv on Tru64 should have gone on in bug 197051 and this bug should have focused on running Mozilla with the system libiconv. However, too much has been written here so it's too late (i mixed up who reported which bug). Anyway, is there any way you can install iconv(3) modules for UTF-8/UTF-16 provided by HP/Compaq? With that, Mozilla should work fine.
Hi, so I went to answer your question in comment #14 on the original machine which was used to report bug. We have installed those missing packages, that took for sure a lot more that some 50MB, as it is unclear which had to be installed exactly. Here's what I got: serow.gsf.de# cc test.c -L/usr/lib -liconv serow.gsf.de# ./test bash: ./test: No such file or directory serow.gsf.de# ls a.out* compaq/ cvsco.log make-jars.pl mozilla/ test.c serow.gsf.de# ./a.out Usage: iconv_test (UTF-16|UTF-16LE|UTF-16BE) serow.gsf.de# ./a.out UTF-16 codeset = ISO8859-1 out[0]=feff, outlen=0 out[0]= 20, outlen=2 serow.gsf.de# ldd a.out Main => a.out libiconv.so => /usr/shlib/libiconv.so libc.so => /usr/shlib/libc.so serow.gsf.de# ./a.out UTF-16BE codeset = ISO8859-1 out[0]=fffe, outlen=0 out[0]=2000, outlen=2 serow.gsf.de# ./a.out UTF-16LE codeset = ISO8859-1 out[0]=feff, outlen=0 out[0]= 20, outlen=2 serow.gsf.de# It seems one need packages like (configure could look for hem using "setld -i | grep IOSWW" command: IOSWWBASE520 installed Worldwide Base System (Worldwide Language Support - Operating System) IOSWWEURLOC520 installed Worldwide European Unicode Locales (Worldwide Language Support - Operating System) IOSWWFGC520 installed Worldwide Composite Unicode Fonts (Worldwide Language Support - Windowing Environment) IOSWWFONTP520 installed Worldwide DECwindows Additional Fonts(Worldwide Language Support - Windowing Environment) IOSWWLAT9LOC520 installed Worldwide Single-Byte Latin-9 Locales(Worldwide Language Support - Operating System) IOSWWMULE520 installed Worldwide MULE (Worldwide Language Support - General Applications) IOSWWOBSOLETE520 installed Worldwide Obsolete Commands and Utilities(Worldwide Language Support - Obsolete Components) IOSWWPGMR520 installed Worldwide Software Development (Worldwide Language Support - Software Development) IOSWWX11520 installed Worldwide Basic X Environment (Worldwide Language Support - Windowing Environment) IOSWWXDEV520 installed Worldwide X Window Software Development(Worldwide Language Support - Software Development) IOSWWXFR520 installed Worldwide Two-Byte Outline Font Renderer(Worldwide Language Support - Windowing Environment)
Can I force mozilla to get compiled without GNU libiconv? I cannot omit the path into that directory where it is installed, as other libs and binaries like zip(1) are in there are and are required by configure. Regarding your comment #18 and missing libgcc*.so, modify your LD_LIBRARY_PATH to include the directory where it is located. I believe "gcc -print-libgcc-file-name " is your friend on HP testdrive machine. BTW: Why don't you use CC/CXX variables to force usage of vendor cc/cxx compilers?
Thanks for testing. So, HP/Compaq document tells the truth :-). iconv(3) on Tru64 works correctly judging from your test result. As for the installation, I guess, in your case (unless you need to use non-European languages as well), you can just do with the first two packages. Now that you installed all of them( 50MB is nothing in this age of cheap disks, right?) :-), could you do some more test for me (which we asked in comment #4 and #5, but we've never gotten answer for from Japan) $ locale -a | grep ja There will be at least one entry (more likely two or three). Set LC_ALL to each of them, and run my test program. $ export LC_ALL=ja (suppose one of Japanese locales listed is 'ja') $ do my test here As for HP test drive machines, thanks for the tip. So, I have to set CC/CXX variables to use vendor-compilers instead of gcc/g++. Anyway, those machines wouldn't help me fix this bug because on them hardly any I18N package is installed.
QA Contact: amyy → i18n
True64 build support got removed
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: