Closed Bug 160180 Opened 22 years ago Closed 20 years ago

Unable to build on NetBSD

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
NetBSD
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7final

People

(Reporter: fn, Assigned: dougt)

References

Details

(Keywords: fixed1.7)

Attachments

(1 file, 2 obsolete files)

second update of the patch
3.38 KB, patch
cls
: review+
asa
: approval1.7+
Details | Diff | Splinter Review 
When I try to build on NetBSD-1.5.2, I get the following error:

nsNativeCharsetUtils.cpp: In function `static void
nsNativeCharsetConverter::LazyInit()':
nsNativeCharsetUtils.cpp:255: `CODESET' undeclared (first use this function)
nsNativeCharsetUtils.cpp:255: (Each undeclared identifier is reported only once
nsNativeCharsetUtils.cpp:255: for each function it appears in.)
gmake[3]: *** [nsNativeCharsetUtils.o] Error 1
Is CODESET defined in any NetBSD system headers?

Over to xpcom. Cc'ing the usual suspects.
Assignee: seawood → dougt
Component: Build Config → XPCOM
QA Contact: granrose → scc
i don't know the first thing about NetBSD, but if i could get access to a NetBSD
system... i'd be more than willing to investigate a solution.
No, CODESET doesn't appear to be in any of the NetBSD system header files.

If an account on the system I work on would help, one can be made available.
-- Felicia
sure, that would help.  basically, we just need to figure out if the wchar_t
format is unicode.  if it is, then we don't even need to bother with trying to
call nl_langinfo.  if it is not, then we need to figure out why our autoconf
tests don't seem to cut the mustard (i.e., they seemed to tell us that CODESET
exists, and yet it doesn't!).
According to the NetBSD developers when asked in wchar_t was unicode:
        no, wchar_t is not UCS4.  you need to handle wchar_t values as opaque
        (we support a lot more things than Unicode, and there's no standard
        that says wchar_t is UCS4).
Felicia Neff wrote:
> According to the NetBSD developers when asked in wchar_t was unicode:

|wchar_t| was never Unicode - neither UCS2 nor UCS4 - only Linux tries to treat
|wchar_t| as UCS2 (which results in the problem that it will never be able to
support locales like ja_JP.PCK that way (IMHO the inventor of the
xx@@@!!!-"|wchar_t|-is-16bit"-idea should burn in h*ll)).
AFAIK a standard-conformant |wchar_t| is >=32bit and the content is
platform+locale-specific and an application must not make any special assumtions
about the used encoding.
then NetBSD definitely needs to use iconv, and that requires being able to call
nl_langinfo(CODESET) to determine the filesystem's charset.
I was able to build previous versions without any problems.  How has this
changed?  It looks like it is CODESET that is the problem.  It is defined for
NetBSD-current but not NetBSD-1.5.
mozilla recently started requiring native unicode -> filesystem charset
conversion.  on windows this means calling MultiByteToWideChar, etc.  and on
unix systems it either means calling mbtowc or iconv.  on unix if wchar_t is not
unicode, then iconv must be used.  but iconv requires knowledge of the src
charset and the destination charset.  the standard way to learn the filesystem
charset under unix is to call nl_langinfo(CODESET).  if this is not supported,
then we have to guess the charset based on the locale, which currently is not
implemented.  we just fallback on ISO-8859-1.  the compilation error is
confusing since it seems to suggest that our configure test is broken.
The config.log isn't very helpful.  Does configure test for nl_langinfo with
CODESET?  If you like, I can run some tests for you.
no, it just test for nl_langinfo
http://lxr.mozilla.org/seamonkey/source/configure.in#1937
1937 AC_CHECK_FUNCS(nl_langinfo strtok_r flockfile)
well, then we need to do better... and we need to figure out what to do if
CODESET is not defined.  we need to guess the charset or something... or is
ISO-8859-1 OK for NetBSD?
On NetBSD-1.6, nl_langinfo(CODESET) returns "646", which is ASCII.  I am
guessing that this is true for NetBSD-1.5 as well.
It has been two months and a couple mozilla releases.  Is there any chance that
anything is going to be done about this problem?
*** Bug 167146 has been marked as a duplicate of this bug. ***
I marked my bug as a duplicate of your bug. I did try to find whether it  
was already a reported issue when I submitted my bug but I did
oversee this bug.

FYI:

gettext ships in codeset.m4 the following autoconf test for nl_langinfo(CODESET):


AC_DEFUN([AM_LANGINFO_CODESET],
[
  AC_CACHE_CHECK([for nl_langinfo and CODESET], am_cv_langinfo_codeset,
    [AC_TRY_LINK([#include <langinfo.h>],
      [char* cs = nl_langinfo(CODESET);],
      am_cv_langinfo_codeset=yes,
      am_cv_langinfo_codeset=no)
    ])
  if test $am_cv_langinfo_codeset = yes; then
    AC_DEFINE(HAVE_LANGINFO_CODESET, 1,
      [Define if you have <langinfo.h> and nl_langinfo(CODESET).])
  fi
])

I think these are the steps to use this test

add codeset.m4 to <MOZDIR>/build/autoconf/

in configure.in change

  AC_CHECK_FUNCS(nl_langinfo flockfile)

to 

  AC_CHECK_FUNCS(flockfile)
  AM_LANGINFO_CODESET()

and then change all occurances of

  HAVE_NL_LANGINFO

to

  HAVE_LANGINFO_CODESET

Darin/Doug - what is the opinion on the last two suggested fixes to 
codeset.m4 - did this stop happening, maybe?

I am no developer, and this comment is only to show my interest in seing this 
bug touched - I will gladly test any experimental changes for the NetBSD build.

Are there no PCs at @netscape.com, Darin, where you could install NetBSD? I 
only have an old laptop, very little free space, plus my compiles take a long 
time - not to mention that Mozilla on NetBSD seems slower than the linux build.
FYI:
This bug still exists in Mozilla 1.4.1
sorry guys... this is very low on my priority list.  hopefully someone with an
already existing NetBSD setup can give Brian's suggested fix a try.
This patch is a suggested fix against Mozilla 1.6 .

Please doublecheck it - I'm not very familar with the autoconf setup in
Mozilla.
this is gpl code and therefore not usable for mozilla. (last file in the patch).
sorry, I saw the exception clause only later, so nevermind me.
Flags: blocking1.7?
Comment on attachment 139821 [details] [diff] [review]
suggested fix (roughly similar to Brian's suggestion)

hm... why do you have 
+AC_SUBST(HAVE_LANGINFO_CODESET)
in configure.in, and what is the autoconf.mk.in change for?
Attachment #139821 - Flags: review?(bsmedberg)
As said, I'm not very familar with the autoconf setup in Mozilla.

AM_LANGINFO_CODESET might define HAVE_LANGINFO_CODESET.

What is the correct way to pass a #define from configure to the C++ files?


(In reply to comment #26)
> What is the correct way to pass a #define from configure to the C++ files?

Well, AC_DEFINE as usual - the codeset.m4 file does that already.

AC_SUBST passes stuff to Makefiles, which can access it as @FOO@
Attached patch updated patch (obsolete) — — Splinter Review 
Thanks for this explanations.

I've tried a build without the two parts you noted and it works.

Is this updated patch OK, or are there still problems with it?
Attachment #139821 - Attachment is obsolete: true
Attachment #148043 - Attachment description: updated patchj → updated patch
I'd like to defer that question to bsmedberg who knows the build system stuff
better than me...
Comment on attachment 139821 [details] [diff] [review]
suggested fix (roughly similar to Brian's suggestion)

passing the buck ;)
Attachment #139821 - Flags: review?(bsmedberg) → review?(cls)
Comment on attachment 139821 [details] [diff] [review]
suggested fix (roughly similar to Brian's suggestion)

Neither this patch (nor the one not marked as obsolete) contain the change to
remove the old check for nl_langinfo.
Attachment #139821 - Flags: review?(cls) → review-
Thanks for your comments.

This version of the patch completely removes the nl_langinfo() check.

It's made against 1.6, but it applies against current 1.7 branch, and I've
checked that it is also correct against 1.7 .
Attachment #148043 - Attachment is obsolete: true
Attachment #148153 - Flags: review?(cls)
Attachment #148153 - Flags: review?(cls)
Attachment #148153 - Flags: review+
Attachment #148153 - Flags: approval1.7?
Comment on attachment 148153 [details] [diff] [review]
second update of the patch

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #148153 - Flags: approval1.7? → approval1.7+
Status: UNCONFIRMED → NEW
Ever confirmed: true
The patch has been checked in on the trunk & the 1.7 branch.
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.7?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.7final
Keywords: fixed1.7
*** Bug 256069 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: