On 05-Jan-30 05:50, Steve Langasek wrote: > Hi Andreas, > > On Sun, Jan 30, 2005 at 02:12:56PM +0100, Andreas Jochens wrote: > > Please reconsider using a newer version of Berkeley DB. The old 'db3' > > version > > has problems on the amd64 and ppc64 architectures. > > What problems does db3 have on these architectures?
Hi Steve, thank you for your reply! The 'db3' package FTBFS on both amd64 and ppc64 for different reasons. On amd64 the problem is related to the exclusive use of NPTL instead of LinuxThreads. This problem can be solved by patching the 'db3' package and/or the packages which have 'libdb3-dev' in their Build-Depends. However, this problem with 'db3' on amd64 is known for more than half a year it has not been solved up to now. On ppc64, the 'db3' package does not build at all and I do not know any patch or solution for this. The build stops with the following error which seems to be releated to the use of weak symbols: gcc -shared -Wl,-Bsymbolic -Wl,--version-script=Versions cxx_app.lo cxx_except.lo cxx_lock.lo cxx_log.lo cxx_mpool.lo cxx_table.lo cxx_txn.lo -lstdc++ -L.libs/ -ldb3 -lc -Wl,-soname -Wl,libdb3_cxx.so.3 -o .libs/libdb3_cxx.so.3.0.2 /usr/bin/ld: cxx_app.lo(.text+0x330): unresolvable R_PPC64_REL24 relocation against symbol `.__db_real_err@@DB3_2' > > Upgrading should not be that difficult. Many other packages already > > switched > > to newer versions without problems. > > I think it would be a good idea to upgrade to db4.2, but I believe this > requires additional code to handle automatic upgrades of the on-disk > database format, which you did not provide a patch for. Even if a patch > were available, I would be wary of doing this before the sarge release > because of the limited window of opportunity for testing the change. The amd64 and ppc64 architectures will not be released with sarge anyway. Consequently, it is not be necessary to solve this before sarge. I am not sure if extra code for automatic upgrades will be necessary or even helpful in this case. If I understand it correctly, the 'pam' package does not provide or create any .db database files itself. Instead other packages or the system administrator may instruct 'pam' to use external .db database files with user data for authentication purposes. It does not seem to be a good idea to automatically change such external files. However, I did not look very closely on this and I maybe wrong here. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
