wchar_t in Linux

[Heinrich Wolf]

Hello,

which lib must I add for wchar_t?

cc -o nim nim.c -lcurses
/tmp/ccD8wZTE.o: In function `SetHolz':
nim.c.text+0x23b): undefined reference to `addwstr'
nim.c.text+0x24a): undefined reference to `addwstr'
collect2: ld gab 1 als Ende-Status zurück
make: *** [nim] Fehler 1

kind regards
Heiner

 

[Ian Collins]

Hello,

which lib must I add for wchar_t?

cc -o nim nim.c -lcurses
/tmp/ccD8wZTE.o: In function `SetHolz':
nim.c.text+0x23b): undefined reference to `addwstr'

That's a curses function, man is your friend.

 

[Heinrich Wolf]

....

That's a curses function, man is your friend.

Hello Ian,

I already read google and man pages. But I did not yet find out. Did you see
that I already have -lcurses in my make statement?

Heiner

 

[Ian Collins]

....

Hello Ian,

I already read google and man pages. But I did not yet find out. Did you see
that I already have -lcurses in my make statement?

Did you include curses.h?

If you did, I suggest you take the question to a Linux group.

 

[Heinrich Wolf]

Of course I did.

I did and I got the same error. `grep -r addwstr /usr/include` doesn't
find
the string on either OpenBSD or Linux.

The compiler did not complain about addwstr. Only the linker did.

 

[Martin Ambuhl]

Hello,

which lib must I add for wchar_t?

It is normally not a library you need to add, but a header
#include <wchar.h>

It may be sometimes useful to also
#include <wctype.h>

Your implementation may fall short of supplying full support for
wchar_t. Your error messages suggest another problem

cc -o nim nim.c -lcurses
/tmp/ccD8wZTE.o: In function `SetHolz':
nim.c.text+0x23b): undefined reference to `addwstr'
nim.c.text+0x24a): undefined reference to `addwstr'
collect2: ld gab 1 als Ende-Status zurück
make: *** [nim] Fehler 1

It is conceivable that I missed the addition of "addwstr" to the
standard C libraries, but I doubt it. My guess is that whatever package
you got "nim.c" from included files containing this almost certainly
non-standard function and you forgot to link it (possibly even to
compile it).

 

[Heinrich Wolf]

....

It is normally not a library you need to add, but a header
#include <wchar.h>

....
It's already in nim.c

 

[Harald van Dijk]

Hello,

which lib must I add for wchar_t?

cc -o nim nim.c -lcurses
/tmp/ccD8wZTE.o: In function `SetHolz':
nim.c.text+0x23b): undefined reference to `addwstr'
nim.c.text+0x24a): undefined reference to `addwstr'
collect2: ld gab 1 als Ende-Status zurück
make: *** [nim] Fehler 1

The compiler did not complain about addwstr. Only the linker did.

Looking at how you're invoking the compiler, you're not asking it to
tell you when anything is wrong. Unfortunately, for several compilers,
including gcc which you are probably using, no warning is emitted by
default for implicit function declarations. First, try enabling
warnings. If you still get no warning for the implicit function
declaration, then you're using the header files for the wide-char-
aware version of ncurses, but linking with the non-wide-char-aware
version (which suggests the problem is with your (distro's) setup).
But if you do get a warning after that, then it's just because you
aren't using the wide-char-aware version of ncurses. How to install
and use that depends on exactly what system you're running. It may be
available as a replacement for the lib(n)curses you have installed
now, or it may install its header files and library using another name.

 

[Heinrich Wolf]

Looking at how you're invoking the compiler, you're not asking it to
tell you when anything is wrong. Unfortunately, for several compilers,
including gcc which you are probably using, no warning is emitted by
default for implicit function declarations. First, try enabling
warnings. If you still get no warning for the implicit function
declaration, then you're using the header files for the wide-char-
aware version of ncurses, but linking with the non-wide-char-aware
version (which suggests the problem is with your (distro's) setup).

<Heiner>
Which include is for the wide-char-aware version of ncurses?
I have #include <curses.h> and I also tried #include <ncurses.h>
Which lib is for the wide-char-aware version of ncurses?
I have -lcurses and I also tried -lncurses .
</Heiner>

But if you do get a warning after that, then it's just because you
aren't using the wide-char-aware version of ncurses. How to install
and use that depends on exactly what system you're running. It may be
available as a replacement for the lib(n)curses you have installed
now, or it may install its header files and library using another name.

<Heiner>
I use Fedora 14
</Heiner>

kind regards
Heiner

 

[Ralph Spitzner]

Hello,

which lib must I add for wchar_t?

cc -o nim nim.c -lcurses

Try -lcursesw
^
-rasp

 

[Ian Collins]

Of course I did.

Well then, there's not a lot we can do to help without the source for
your C file.

 

[Ian Collins]

I did and I got the same error. `grep -r addwstr /usr/include` doesn't find
the string on either OpenBSD or Linux. On OS X I need to define
_XOPEN_SOURCE_EXTENDED, even though a cursory investigation of the XCURSES
standard suggests _XOPEN_SOURCE should be sufficient, although I've never
done any curses work.

A noddy test

#include <curses.h>

int main()
{
wchar_t *wstr;

addwstr(wstr);
}

compiles and links fine on Solaris.

 

[Heinrich Wolf]

Heinrich Wolf wrote: ....
Try -lcursesw

Thanks a lot! That solved the linker issue. But now I have the next
question: How do I declare a wchar_t * constant so that it looks like a
quick match, similar to "o---", using the information from the charmap
(screenshot http://www.wolf-fuerth.de/charmap.png )?

I tried this without success:

wchar_t *Holz2 = L"o\x25\x00\x25\x00\x25\x00";

and this:

wchar_t *Holz2 = L"\x00o\x25\x00\x25\x00\x25\x00";

addwstr(Holz2);

kind regards

 

[Ben Bacarisse]

Thanks a lot! That solved the linker issue. But now I have the next
question: How do I declare a wchar_t * constant so that it looks like
a quick match, similar to "o---", using the information from the
charmap (screenshot http://www.wolf-fuerth.de/charmap.png )?

I tried this without success:

wchar_t *Holz2 = L"o\x25\x00\x25\x00\x25\x00";

and this:

wchar_t *Holz2 = L"\x00o\x25\x00\x25\x00\x25\x00";

No, you don't have to guess the byte order. You do this:

L"o\x2500\x2500\x2500"

Remember also to call setlocale, or the output system might no be able
to render these characters in the proper encoding for your device.

 

[Heinrich Wolf]

No, you don't have to guess the byte order. You do this:

L"o\x2500\x2500\x2500"

Remember also to call setlocale, or the output system might no be able
to render these characters in the proper encoding for your device.

Thanks a lot!

With L"o\x2500\x2500\x2500" the output looks much better than with
L"o\x25\x00\x25\x00\x25\x00". Now I'm googling about the right ? in
setlocale(LC_CTYPE, "de_DE.?") based upon the charmap screenshot
http://www.wolf-fuerth.de/charmap.png .

kind regards
Heiner

 

[Harald van Dijk]

No, you don't have to guess the byte order.  You do this:

  L"o\x2500\x2500\x2500"

Better yet, do this:

L"o\u2500\u2500\u2500"

The encoding of characters is not something you should normally
concern yourself with, IMO. Let the compiler determine that \u2500
simply maps to \x2500.

(\u???? is not valid in C90, but is valid in C99, and is supported by
GCC.)

 

[Ben Bacarisse]

Thanks a lot!

With L"o\x2500\x2500\x2500" the output looks much better than with
L"o\x25\x00\x25\x00\x25\x00". Now I'm googling about the right ? in
setlocale(LC_CTYPE, "de_DE.?") based upon the charmap screenshot
http://www.wolf-fuerth.de/charmap.png .

The screen shot is not a lot of help. It shows part of the Unicode
character map but it does suggest you are using Windows and I don't know
how locales work in Windows. The C standard says very little about the
actual strings you use. I think you should ask in a Windows group. Be
sure to say what;s wrong -- i.e. what it is that happens now and what
you'd like to happen. Saying that "the output looks much better" won't
be enough!

 

[Ben Bacarisse]

Better yet, do this:

L"o\u2500\u2500\u2500"

The encoding of characters is not something you should normally
concern yourself with, IMO. Let the compiler determine that \u2500
simply maps to \x2500.

You are right, though the possibility of any other mapping is very
slight these days.

(\u???? is not valid in C90, but is valid in C99, and is supported by
GCC.)

The OP's headers suggested Windows so there's a chance the OP is using a
compiler that does not understand \u????.

 

[Heinrich Wolf]

....

The screen shot is not a lot of help. It shows part of the Unicode
character map but it does suggest you are using Windows and I don't know
how locales work in Windows. The C standard says very little about the
actual strings you use. I think you should ask in a Windows group. Be
sure to say what;s wrong -- i.e. what it is that happens now and what
you'd like to happen. Saying that "the output looks much better" won't
be enough!

No no!
I am using f14 Linux and it is the charmap from gnome.

kind regards
Heiner

 

[Heinrich Wolf]

Better yet, do this:

L"o\u2500\u2500\u2500"

The encoding of characters is not something you should normally
concern yourself with, IMO. Let the compiler determine that \u2500
simply maps to \x2500.

(\u???? is not valid in C90, but is valid in C99, and is supported by
GCC.)

[Heiner]

Thanks a lot!
That changes output a bit.
\x2500 is shown as a blank
\u2500 is not shown at all

I am still searching what is the right parameter for setlocale
( http://www.wolf-fuerth.de/charmap.png )