Unable to build on NetBSD

RESOLVED FIXED in mozilla1.7final



17 years ago
15 years ago


(Reporter: fn, Assigned: dougt)




Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)



17 years ago
When I try to build on NetBSD-1.5.2, I get the following error:

nsNativeCharsetUtils.cpp: In function `static void
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

Comment 2

17 years ago
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.

Comment 3

17 years ago
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

Comment 4

17 years ago
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!).

Comment 5

17 years ago
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).

Comment 6

17 years ago
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.

Comment 7

17 years ago
then NetBSD definitely needs to use iconv, and that requires being able to call
nl_langinfo(CODESET) to determine the filesystem's charset.

Comment 8

17 years ago
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.

Comment 9

17 years ago
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.

Comment 10

17 years ago
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.

Comment 11

17 years ago
no, it just test for nl_langinfo
1937 AC_CHECK_FUNCS(nl_langinfo strtok_r flockfile)

Comment 12

17 years ago
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?

Comment 13

17 years ago
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.

Comment 14

17 years ago
It has been two months and a couple mozilla releases.  Is there any chance that
anything is going to be done about this problem?

Comment 15

17 years ago
*** Bug 167146 has been marked as a duplicate of this bug. ***

Comment 16

17 years ago
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.

Comment 17

17 years ago

gettext ships in codeset.m4 the following autoconf test for nl_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);],
  if test $am_cv_langinfo_codeset = yes; then
      [Define if you have <langinfo.h> and nl_langinfo(CODESET).])

Comment 18

17 years ago
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)



and then change all occurances of



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.

Comment 20

16 years ago
This bug still exists in Mozilla 1.4.1

Comment 21

16 years ago
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.

Comment 22

15 years ago
Created attachment 139821 [details] [diff] [review]
suggested fix (roughly similar to Brian's suggestion)

This patch is a suggested fix against Mozilla 1.6 .

Please doublecheck it - I'm not very familar with the autoconf setup in
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.


15 years ago
Flags: blocking1.7?
Comment on attachment 139821 [details] [diff] [review]
suggested fix (roughly similar to Brian's suggestion)

hm... why do you have 
in configure.in, and what is the autoconf.mk.in change for?
Attachment #139821 - Flags: review?(bsmedberg)

Comment 26

15 years ago
As said, I'm not very familar with the autoconf setup in Mozilla.


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@

Comment 28

15 years ago
Created attachment 148043 [details] [diff] [review]
updated patch

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


15 years ago
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 30

15 years ago
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 31

15 years ago
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-

Comment 32

15 years ago
Created attachment 148153 [details] [diff] [review]
second update of the patch

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


15 years ago
Attachment #148153 - Flags: review?(cls)


15 years ago
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+
Ever confirmed: true

Comment 34

15 years ago
The patch has been checked in on the trunk & the 1.7 branch.
Last Resolved: 15 years ago
Flags: blocking1.7?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.7final


15 years ago
Keywords: fixed1.7

Comment 35

15 years ago
*** 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.