[csw-maintainers] BerkeleyDB upgrade

[rupert THURNER]

many thanks, now it gets one step further. the error is that configure
tries to use an old db_open (dbopen) ... but i could not figure out
where it gets the idea to try this:

rupert at current9s:~/mgar/pkg/apr-util/trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9
$ /opt/studio/SOS12/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=v8
-xnorunpath -mt -I/opt/csw/include -DSOLARIS2=9
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE
-I/opt/csw/bdb47/include -m32 -xarch=v8 -norunpath -L/opt/csw/lib
-L/opt/csw/bdb47/lib conftest.c -ldb  -lrt
cc: Warning: illegal option -norunpath
"conftest.c", line 33: warning: statement not reached
Undefined                       first referenced
 symbol                             in file
dbopen                              conftest.o
ld: fatal: Symbol referencing errors. No output written to conftest



and one hint was there:
  http://old.nabble.com/undefined-symbol-dbopen-for-BerkeleyDB.4.7-td20439750.html

and another hint here:
http://monkey.org/~dugsong/dsniff/faq.html#Make%20dies%20with%20undefined%20symbol%20{{EX:dbopen}}%20or%20{{EX:__db185_open}}%22

    2.5. Make dies with undefined symbol dbopen  or __db185_open"?
    Be sure to build Berkeley DB with ./configure --enable-compat185.


the program is:

$ cat conftest.c
/* confdefs.h.  */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_UNISTD_H 1
#define HAVE_LBER_H 1
#define HAVE_LDAP_H 1
#define LDAP_SET_REBIND_PROC_THREE 1
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char dbopen ();
int
main ()
{
return dbopen ();
  ;
  return 0;
}






On Fri, Jul 23, 2010 at 14:47, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Maciej,
>
> Am 23.07.2010 um 14:35 schrieb Maciej (Matchek) Blizinski:
>>
>> No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski
>> <maciej at opencsw.org> escreveu:
>>>
>>> No dia 22 de Julho de 2010 20:20, Philip Brown <phil at bolthole.com>
>>> escreveu:
>>>>
>>>> I'm not sure I understand why you are writing this. So, I will add
>>>> more information and hopefully clear things up.
>>>>
>>>> First off, let me say that the existing library search is not
>>>> "perfect". It does not cover all possible library search cases.
>>>> However, it does cover a particular set of interest very well:
>>>>
>>>> If a library has a unique "SONAME", then it will tell you fairly
>>>> accurately which packages have something depending on that SONAME.
>>>>
>>>> Please note: pure "SONAME".  Which is a standalone filename, that has
>>>> no RPATH component to it.o
>>>>
>>>> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it
>>>> accurately tells us which packages need that library.  Which I thought
>>>> was the original question.
>>>
>>> Close, but not exactly.  The original question was: "can we retire
>>> CSWbdb?"  The follow up question was "which packages would break if
>>> the /opt/csw/lib/libdb-4.7.so symlink were removed?"
>>>
>>> The same SONAME is currently provided by two paths, and we're looking
>>> for packages with binaries that meet two criteria:
>>>
>>> 1. need libdb-47.so
>>> 2. don't have /opt/csw/bdb47/lib in the RPATH
>>
>> I've examined the packages and here are the two packages that would
>> break if CSWbdb were removed:
>>
>> CSWap2modperl
>> CSWmodperl
>
> Ok, then I'll remove CSWbdb from the current/ on the buildfarm.
>
>
> Best regards
>
>  -- Dago
>
>