bug-ncurses
[Top][All Lists]
Advanced

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

Re: Trouble linking ncurses on HPE NonStop - missing methods


From: Thomas Dickey
Subject: Re: Trouble linking ncurses on HPE NonStop - missing methods
Date: Tue, 23 Jun 2020 18:15:57 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Jun 23, 2020 at 05:59:19PM -0400, Randall S. Becker wrote:
> On June 23, 2020 5:52 PM, Thomas Dickey wrote:
> > To: Randall S. Becker <rsbecker@nexbridge.com>
> > Cc: bug-ncurses@gnu.org
> > Subject: Re: Trouble linking ncurses on HPE NonStop - missing methods
> > 
> > On Tue, Jun 23, 2020 at 12:01:32PM -0400, Randall S. Becker wrote:
> > > Hi All,
> > >
> > > I have been trying to build the latest ncurses from git for the HPE
> > > NonStop platform. The compiles all go fine under c99, but when linking
> > > happens, we hit missing procs for attorn and attroff in one location.
> > > I would appreciate some assistance getting past this. I suspect I'm
> > > missing some define or
> > > include:
> > 
> > It's more likely a "-I" option inherited from your CFLAGS or CPPFLAGS
> > environment variable (or even CC, since it seems some people do that).
> 
> The linker is called by CC - I was trying to get the underlying command.
> However, all other tests compiled and linked perfectly. This was the only
> test that did not link.

What's different about that one is that I made it use the actual function
rather than allowing it to use the macro:

extern NCURSES_EXPORT(int) attron (NCURSES_ATTR_T);                     /* 
generated */

vs

#define attron(at)              wattron(stdscr,(at))

with this code:

#ifdef NCURSES_VERSION
        (attron) ((int) color); /* quieter compiler warnings */
#else
        attron(color);          /* PDCurses, etc., either no macro or wrong */
#endif

Offhand, there's a couple of possibilities:

a) there was some problem generating ncurses/lib_gen.c (and the corresponding
   lib_gen.o doesn't have that symbol), or

b) the linker is ignoring the -L option (which I've seen occasionally when
   building shared libraries).
   
   If it's the latter, that can usually be worked-around by setting
   LD_LIBRARY_PATH while building (e.g., using misc/shlib).

I'd start by looking at the symbols in the ncurses library (in lib)
and the lib_gen.o (in obj*).

> The actual command was:
> 
> cc  -o blue ../obj_s/blue.o  -I. -I. -I../test -DHAVE_CONFIG_H
> -DDATA_DIR=\"/usr/local/share\" -I. -I../include -D_POSIX_C_SOURCE=199506L
> `echo "-L../lib -lform -lmenu -lpanel -lncurses   " | sed -e
> 's/-lform.*-lpanel[^ ]*//'`  
> 
> 
> > The linker commands won't show that.
> > 
> > > eld command line:
> > >    /usr/bin/eld -o blue -set systype oss -set highpin on -set
> > > highrequestor on
> > >    -set inspect on /usr/lib/ccplmain.o -call_shared ../obj_s/blue.o
> -L../lib
> > >    -lncurses -L/usr/local/lib -lfloss -lutil -lrld -optional_lib -L
> > >    /G/system/sys04 -lcre -lcrtl -lossk -lossf -lsec -li18n -licnv -losse
> > >    -linet -lossh -lossc -no_optional_lib -allow_duplicate_procs
> > >
> > > **** ERROR **** [1210]:
> > >    ../obj_s/blue.o: In function `printcard':
> > >    ../obj_s/blue.o(.text._151958720+0x302): unresolved reference to
> > attron.
> > > **** ERROR **** [1210]:
> > >    ../obj_s/blue.o(.text._151958720+0x382): unresolved reference to
> > attroff.
> 

-- 
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]