On Sun, Jan 30, 2005 at 03:34:03PM +0100, Andreas Jochens wrote: > 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? > thank you for your reply! > The 'db3' package FTBFS on both amd64 and ppc64 for different reasons. It actually no longer FTBFS on amd64; I was expecting this fix, but didn't want to comment before I saw the result for myself. > 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' Hmm, no insights into that one. Sounds like one of many reasons to try to move to db4.2 when possible. > 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. Ah, good point. In that case, we just have to be able to open those files in a mode compatible with existing on-disk db3 formats. Thanks, -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
