Re: unresolved symbols with ncurses-5.6 on Alpha OSF1 5.1A

[Martin MOKREJŠ]

Hi Thomas,
 thanks for your input. cxx is a C compiler, CXX is a C++ compiler. That's how 
they are
named on alphas. Setting the env variables on the configure commandline always 
worked
fine for me in the past.

 It seems this is a more general issue, I get the same even with gcc:

make[1]: Entering directory `/usr/home3/mmokrejs/ncurses-5.6/progs'
sh ./MKtermsort.sh nawk ./../include/Caps >termsort.c
echo "#define PROG_CAPTOINFO \"`echo captoinfo|   sed 's/$//'|sed 's,x,x,'|sed 
's/$//'`\"" >transform.h
echo "#define PROG_INFOTOCAP \"`echo infotocap|   sed 's/$//'|sed 's,x,x,'|sed 
's/$//'`\"" >>transform.h
echo "#define PROG_RESET     \"`echo reset|       sed 's/$//'|sed 's,x,x,'|sed 
's/$//'`\""     >>transform.h
echo "#define PROG_INIT      \"`echo init|        sed 's/$//'|sed 's,x,x,'|sed 
's/$//'`\""      >>transform.h
gcc -I../progs -I. -DHAVE_CONFIG_H -I. -I../include  -D_OSF_SOURCE -DNDEBUG 
-I/usr/home3/mmokrejs/include/ncurses -O2 -c ../progs/tic.c -o ../objects/tic.o
gcc -I../progs -I. -DHAVE_CONFIG_H -I. -I../include  -D_OSF_SOURCE -DNDEBUG 
-I/usr/home3/mmokrejs/include/ncurses -O2 -c ../progs/dump_entry.c -o 
../objects/dump_entry.o
gcc ../objects/tic.o ../objects/dump_entry.o -L../lib -lncurses -L../lib 
-lncurses    -I../progs -I. -DHAVE_CONFIG_H -I. -I../include  -D_OSF_SOURCE 
-DNDEBUG -I/usr/home3/mmokrejs/include/ncurses -O2 -o tic
_nc_first_name
_nc_set_type
_nc_curr_line
_nc_write_entry
_nc_doalloc
_nc_name_match
_nc_rootname
use_extended_names
_nc_disable_period
_nc_tracing
_nc_check_termtype2
_nc_set_source
_nc_read_entry_source
_nc_resolve_uses2
_nc_head
_nc_curr_col
_nc_tic_written
_nc_tic_dir
_nc_tail
_nc_set_writedir
_nc_warning
_nc_capcmp
_nc_visbuf2
_nc_visbuf
_nc_tparm_err
tparm
_nc_syntax
_nc_tinfo_fkeys
strnames
_nc_trim_sgr0
keyname
_nc_get_hash_table
_nc_find_entry
strcodes
boolcodes
numcodes$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/alphaev68-dec-osf5.1/3.3.4/specs
Configured with: ../gcc-3.3.4/configure 
Thread model: single
gcc version 3.3.4

boolnames
numnames
boolfnames
numfnames
strfnames
_nc_tic_expand
_nc_user_definable
_nc_infotocap
collect2: ld returned 1 exit status
make[1]: *** [tic] Error 1


$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/alphaev68-dec-osf5.1/3.3.4/specs
Configured with: ../gcc-3.3.4/configure 
Thread model: single
gcc version 3.3.4
$

Martin

Thomas Dickey wrote:
> On Mon, 16 Apr 2007, Martin MOKREJŠ wrote:
>
> > Thomas Dickey wrote:
> > > On Mon, 16 Apr 2007, Martin MOKREJŠ wrote:
> > >
> > > > Hi Thomas,
> > > > I tried to compile ncurses on some forgotten Alpha machine and I got
> > > > the following:
> > > >
> > > > CC=cxx CXX=cxx CFLAGS="-tune ev56 -arch ev56" ./configure 
> > > > --prefix=$HOME
> > >      ^^^ (I'd expect that to be a C++ compiler).
> > >
> > > That might work - at compile-time - but at configure time, lots of
> > > checks would probably fail (making the #define's not reliable).
> > >
> > > But the errors seem more like those from problems linking a shared
> > > library.  I don't see that in the command-line.
> ...
> > Unresolved:
> > cur_term
> > setupterm
> > tputs
> > tao$ ls ../lib/libncurses
> > libncurses.a    libncurses_g.a  tao$
> >
> >
> >
> > So I suspect somehow static libs are being built in my case by default.
>
> ok.  But missing symbols sounds like either the "cxx" is building objects
> that the linker isn't finding in those archives, or that "cxx" isn't
> looking there.  You can see if they're defined in the archives using
> "nm".  To me "cxx" means C++, so "nm -C" would (on more than one 
> platform) be used to see the C++ names.  However, the __cplusplus 
> ifdef's in the
> headers are supposed to make those names all "C" rather than "C++".
> If the "nm" output shows some odd names that "nm -C" fixes, that's 
> possibly where the problem is.  Otherwise, check/see if the compiler can 
> tell you what files it's opening.

--
Dr. Martin Mokrejs
Dept. of Genetics and Microbiology
Faculty of Science, Charles University
Vinicna 5, 128 43 Prague, Czech Republic
http://www.iresite.org
http://www.iresite.org/~mmokrejs