bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Problem] wattr_get symbol not defined when compiling with UTF8 supp


From: Thomas Dickey
Subject: Re: [Problem] wattr_get symbol not defined when compiling with UTF8 support
Date: Fri, 21 Aug 2020 19:46:15 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Aug 21, 2020 at 06:05:30PM -0400, Randall S. Becker wrote:
> I'm having some trouble building ncurses 6.2 with wide/utf8 support on
> NonStop. The linker is reporting the following:
> 
> xld command line:
>    /usr/bin/xld -o ncurses -set systype oss -set highpin on -set 
> highrequestor 
>    on -set inspect on /usr/lib/ccpmainx.o ../obj_s/ncurses.o -L../lib -lformw 
>    -lmenuw -lpanelw -lncursesw -L/usr/local/lib -lfloss -lutil -lrld -L 
>    /G/system/sys07 -lcre -lcrtl -lossk -lossf -lsec -li18n -licnv -losse 
>    -linet -lossh -lossc -allow_duplicate_procs 

One or more of the library dependencies may use something like terminfo
which would pull in the curses library.  Running "nm" on those libraries
would show that.  In that case, it's not easily fixable since the
symbols don't necessarily match up.  This used to be a problem with
Solaris (where the acs_map is named differently).
    
> **** ERROR **** [1210]:
>    ../obj_s/ncurses.o: In function `wide_show_attr':
>    ../obj_s/ncurses.o(.text+0x60a6): unresolved reference to wattr_get.
>  
> The build has wattr_on.c and wattr_off.c, but I'm concerned that wattr_get
> is assuming curses.

If you don't see a clue via "nm" -

Most compilers have a verbose-option that would show the libraries that
are used - perhaps the loader xld can do that too - I'd start there.

(when that fails, some systems have strace or truss, which can show
the system calls used -- including file opening).
 
> I'm not sure why this might be, since this is apparently defined. Any
> pointers on resolving this?

The linker's probably preferring the search-path for the system's
shared libraries over the -L option.  On most systems you can help
the linker by setting an environment variable (probably documented in the
xld's manpage).  That works for building, though after installing you
may still have to have built with appropriate options for making the
dynamic loader pick up the right library.

Of course, some are just broken (such as OpenBSD's 64-bit port over the
past year or so, which ignores the -L option and so forth).
But most systems aren't _that_ bad.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]