On Fri, Feb 01, 2002 at 05:21:06PM -0500, Victor wrote:
> > Now that you mention it, the link line doesn't include -lrpc2 because
> > dirtest shouldn't even be using any functions from 'getsecret', so why
> > is the linker complaining?
> 
> Compiler verson:
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
> 
> Damn, is it because of 2.96?

Could very well be, I've used 2.7.* and 2.95.* successfully. We've
already managed to identify one case where 3.0.* was miscompiling Coda.
And I believe 2.96 was a 3.0 beta version, so it can very well have not
just the normal 'Coda is doing something stupid with C vs. C++', but
also the 'beta-3.0' bugs.

> I added it and dir compiled fine. But then another error came right
> afterwards:
> 
...
> gcc -fno-exceptions -L/usr/coda/lib -L/usr/coda/lib -L/usr/coda/lib
> pdbtool.o libal.a ../util/libutil.a /usr/home/victord/CO
> DA/coda-5.3.17/lib-src/base/libbase.a -ldb1   -lreadline -ltermcap -o
> pdbtool
> ../util/libutil.a(getsecret.o): In function `GenerateSecret(unsigned char
> *)':
> getsecret.o(.text+0x1f2): undefined reference to `rpc2_NextRandom'

Same problem, pretty much everything linked against libbase will have
the same thing. And neither splitting up libbase, nor linking everything
against librpc2 is a good solution. Maybe not using the rpc2 random
number generating function in lib-src/base/getsecret.c would be better?

Jan