> 
> I can't begin to guess how constant.o came to be looking
> for the symbols you are reporting.
> 
> Mebbe a busted libtool injecting additional libraries from a random *.la 
> file?
> 
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org


Ok, I believe I see what is going on, but it's going to take a minute to 
go throw so please bear with me... I'm definitely not a libtool or ld 
expert ;)

Unless I'm completely off the path, the gist of it is everything is 
traceable back to rpmcontstabt.c. I'm going to be using rpmds as an 
example since many of the missing symbols are from that group, they 
don't exist at all in JBJ's output, at it is conveniently the name of a 
the same header.

Here's the walk through:

gmake[3]: Entering directory 
`/usr/local/src/rpm-packages/BUILD/rpm-5.0a1/rpmconstant'
source='rpmconstant.c' object='rpmconstant.lo' libtool=yes \
         DEPDIR=.deps depmode=none /bin/bash ../depcomp \
         /bin/bash ../libtool --tag=CC   --mode=compile cc 
-DHAVE_CONFIG_H -I. -I..  -I. -I.. -I../build -I../lib -I../rpmdb 
-I../rpmio -I../misc -I/usr/local/include -I/usr/local/include/python2.4 
    -I/usr/local/include/beecrypt -I/usr/local/ssl/include 
-DRPM_OS_SOLARIS=020900 -I/usr/local/include/neon    -g -xs 
-D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DNE_LFS   -c -o 
rpmconstant.lo rpmconstant.c
mkdir .libs

The first thing that is built is rpmconstant, which is immediately turn 
into a pic object:

  cc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../rpmdb 
-I../rpmio -I../misc -I/usr/local/include -I/usr/local/include/python2.4 
-I/usr/local/include/beecrypt -I/usr/local/ssl/include 
-DRPM_OS_SOLARIS=020900 -I/usr/local/include/neon -g -xs -D_GNU_SOURCE 
-D_REENTRANT -D_LARGEFILE64_SOURCE -DNE_LFS -c rpmconstant.c  -KPIC 
-DPIC -o .libs/rpmconstant.o

The same now is done for rpmconstanttbl and rpmconstant_internal, then 
they are linked together into a shared object:

/usr/ccs/bin/ld -G -h librpmconstant-5.0.so -o 
.libs/librpmconstant-5.0.so  .libs/rpmconstant.o .libs/rpmconstanttbl.o 
.libs/rpmconstant_internal.o  -R/usr/local/lib -R/usr/local/ssl/lib 
-L/usr/local/lib -L/usr/local/ssl/lib -lc

Finally, constant.c is compiled and linked to librpmconstant which is 
specified in the the la and poof we have the missing symbols:

source='constant.c' object='constant.o' libtool=no \
         DEPDIR=.deps depmode=none /bin/bash ../depcomp \
         cc -DHAVE_CONFIG_H -I. -I..  -I. -I.. -I../build -I../lib 
-I../rpmdb -I../rpmio -I../misc -I/usr/local/include 
-I/usr/local/include/python2.4   -I/usr/local/include/beecrypt 
-I/usr/local/ssl/include -DRPM_OS_SOLARIS=020900 
-I/usr/local/include/neon    -g -xs -D_GNU_SOURCE -D_REENTRANT 
-D_LARGEFILE64_SOURCE -DNE_LFS   -c constant.c
"../rpmdb/header.h", line 332: warning: enumerator value overflows 
INT_MAX (2147483647)
"../lib/rpmcli.h", line 155: warning: integer overflow detected: op "<<"
/bin/bash ../libtool --tag=CC   --mode=link cc  -g -xs -D_GNU_SOURCE 
-D_REENTRANT -D_LARGEFILE64_SOURCE -DNE_LFS    -L/usr/local/lib 
-R/usr/local/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib   -o 
rpmconstant constant.o librpmconstant.la -ldl -lm -lpopt -lbeecrypt 
-lpthread -lsocket -lnsl  -lneon
cc -g -xs -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DNE_LFS -o 
.libs/rpmconstant constant.o  -L/usr/local/lib -L/usr/local/ssl/lib 
./.libs/librpmconstant.so -ldl -lm -lpopt -lbeecrypt -lpthread 
/usr/local/lib/libneon.so -lssl -lcrypto -lnsl -lsocket -lz 
/usr/local/lib/libexpat.so  -R/usr/local/lib -R/usr/local/ssl/lib
Undefined                       first referenced
  symbol                             in file
rpmdsInit                           constant.o
etc....

Sorry if I'm oversimplifying this, I'm doing it to get everything 
straight in my head and make sure that if I'm following this wrong 
you'll know. So lets look at what happened along the way.

$ ldd -r .libs/librpmconstant.so
         libc.so.1 =>     /usr/lib/libc.so.1
         libdl.so.1 =>    /usr/lib/libdl.so.1
         /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
         symbol not found: rpmHeaderFormats 
(.libs/librpmconstant.so)
         symbol not found: rpmTagTable           (.libs/librpmconstant.so)
         symbol not found: rpmTags               (.libs/librpmconstant.so)
         symbol not found: hdrVec                (.libs/librpmconstant.so)
         symbol not found: rpmdsTagN             (.libs/librpmconstant.so)
         symbol not found: rpmdsInit             (.libs/librpmconstant.so)
         symbol not found: rpmdsNext             (.libs/librpmconstant.so)
         symbol not found: rpmdsIx               (.libs/librpmconstant.so)
         symbol not found: rpmdsDNEVR            (.libs/librpmconstant.so)
         symbol not found: rpmdsResult           (.libs/librpmconstant.so)
         symbol not found: rpmdsSetResult 
(.libs/librpmconstant.so)
         symbol not found: rpmdsSearch           (.libs/librpmconstant.so)


Those are the same missing symbols... ok so what about the .so's 
components, score on the three object files as well. So where are they 
getting these from since the objects were just created? Lets grep a bit...

rpm-5.0a1/rpmconstant$ /usr/local/gnu/bin/grep -R rpmds *
Binary file constant.o matches
rpmconstant.h:#include <rpmds.h>
Binary file rpmconstant.o matches
Binary file rpmconstant_internal.o matches
rpmconstanttbl.c: * ../lib/rpmds.h
Binary file rpmconstanttbl.o matches

My amateur guess here is that during the creation of the initial objects 
that get linked to the .so, and therefor constant.o, these symbols are 
getting picked up from the recursive headers. It looks like rpmds.h is 
needed twice at compile time and that is only for the rpmds issues, I 
didn't try and trace other missing symbols such as rpmHeaderFormats.

Is there another .libs that it should be linking against? Is it picking 
these up erroneously? Does something here look out of place compared to 
the functional builds?

Hope this helps!
Thanks again,
-Dave

-- 
================================
David Halik
Systems Programmer
OSS/NBCS - OIT Rutgers
dhalik@jla.rutgers.edu
================================