/usr/ccs/bin Unresolved Symbol where symbol exists

[Ray Wagner]

I got this in a big program, but finally tried it ini an extremely simple one and got the same error.

$ cc test.c -c
$ cc myroutine.c -c
$ cc myroutine.o test.o -o test1
No errors so far.
Now I put myroutine.o in an archive and try that.
$ ar -r libTEST.a myroutine.o
ar: creating libTEST.a
$ cc -L/appl/global/cmp/temp -lTEST test.c -o test2
/usr/ccs/bin/ld: Unsatisfied symbols:
myroutine (code)

The myroutine symbol is in the archive but ld doesn't find it.
This is a hello world level test program so there should not be complications like this.

$ nm libTEST.a

Symbols from libTEST.a[myroutine.o]:

Name Value Scope Type Subspace

M$8 |1073741824|static|data |$DATA
$myroutine | 0|extern|entry |$CODE$
printf | |undef |code |

[A. Clay Stephenson · Accepted solution]

In linking order is everything because the linker makes one pass:

BAD:
cc -L/appl/global/cmp/temp -lTEST test.c -o test2

GOOD:
cc -L/appl/global/cmp/temp test.c -lTEST -o test2


You also often have to order multiple libraries from the outermost (with respect to calls) to the innermost.

[Ray Wagner]

Yes, that solves the mystery.
No to get all the C++ modules in the right order...

Thanks,
Ray

[A. Clay Stephenson]

By the way, I trust you are using make rather than scripts (or worse, the command-line itself) to build your projects. Make will "make" things much easier --- especially when libraries are involved.

[Ray Wagner]

I just used the command line there to show what I was doing. The make file had the OBJECTS after the LDFLAGS and that was screwing it up. I normally use a makefile, although like in this case, I don't always look at it too closely.
Thanks again.