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

[Martin MOKREJŠ]

Thomas Dickey wrote:
> On Tue, 17 Apr 2007, Martin MOKREJŠ wrote:
>
> > make[1]: Entering directory `/usr/home3/mmokrejs/ncurses-5.6/progs'
> > 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_infotocap
> > collect2: ld returned 1 exit status
>
> As I noted, you may be able to add an option to gcc to show the specific
> files it opens.  But in the instance where you used -v, I only saw the
> specs file listed.

$ gcc -v ../objects/tic.o ../objects/dump_entry.o -I../progs -I. 
-DHAVE_CONFIG_H -I. -I../include  -D_OSF_SOURCE -DNDEBUG 
-I/usr/home3/mmokrejs/include/ncurses -O2 -o tic -L../lib -lncurses
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
/usr/local/lib/gcc-lib/alphaev68-dec-osf5.1/3.3.4/collect2 -G 8 -O3 -S 
-call_shared -o tic /usr/lib/cmplrs/cc/crt0.o -L../lib 
-L/usr/local/lib/gcc-lib/alphaev68-dec-osf5.1/3.3.4 -L/usr/lib/cmplrs/cc 
-L/usr/local/lib/gcc-lib/alphaev68-dec-osf5.1/3.3.4/../../.. ../objects/tic.o 
../objects/dump_entry.o -lncurses -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
_nc_first_name
_nc_set_type
_nc_curr_line
...
$

> > Making simpler the above compile/linker command while retaining 
> > -lncurses makes the linking step fail again:
> >
> > $ gcc ../objects/tic.o ../objects/dump_entry.o -I../progs -I. 
> > -DHAVE_CONFIG_H -I. -I../include  -D_OSF_SOURCE -DNDEBUG 
> > -I/usr/home3/mmokrejs/include/ncurses -O2 -o tic -lncurses
> > _nc_first_name
> ...
> On this instance I don't see a -L option.

You were right, I forgot that. But still, it does not work:

$ gcc ../objects/tic.o ../objects/dump_entry.o -I../progs -I. -DHAVE_CONFIG_H 
-I. -I../include  -D_OSF_SOURCE -DNDEBUG -I/usr/home3/mmokrejs/include/ncurses 
-O2 -o tic -L../lib -lncurses
_nc_first_name
_nc_set_type
_nc_curr_line
...
$


> So gcc will pick up libncurses from its preferred location, e.g., 
> /usr/local/lib
>
> > Let's link statically the new libncurses.a ...
> >
> > $ gcc ../objects/tic.o ../objects/dump_entry.o ../lib/libncurses.a 
> > -I../progs -I. -DHAVE_CONFIG_H -I. -I../include  -D_OSF_SOURCE 
> > -DNDEBUG -I/usr/home3/mmokrejs/include/ncurses -O2 -o tic
>
> I'd like to solve it this way - but recall some linkers simply put the 
> entire contents of the ".a" file in the output.

But one can test for such broken linkers, right? ;-)