Hi Francois, Thanks very much for your response.
On Sun, 31 Jul 2011 20:01:15 +0200, Francois Tigeot <ftig...@wolfpond.org> wrote: >> In tracing a reproducible bug >> https://bugs.freedesktop.org/show_bug.cgi?id=36843 >> on a Debian squeeze box, I stumbled on missing 'libadabaslo.so' while >> 'libadabasuilo.so' is installed. >> Because LibO 3.3.2 came with both 'libadabasli.so' and 'libabadasuili.so', >> I am wondering whether something has changed expectedly or unexpectedly. > > While investigating a similar issue on NetBSD, I discovered the libadabas* > file was hardcoded to be installed or not depending on the target platform > name. > > This file is the Adabas D client library; a crippled version of the Adabas D > database was bundled with old versions of StarOffice (2000-2003 timeframe). > > Back in June, I found out there was no evidence of this database engine > beeing used after 2004, so I disabled the installation of the library for > all platforms. Thanks, finally I have reached the changes, and also found the missing libadabas irrelevant with the above bug in general because I could not reproduce the one on Mac OS X. But still, if a driver refers to libadabaslo.so should it be fixed? > > If no user is discovered then, all Adabas D code will certainly be removed > from > the trunk after the first release of LibreOffice 3.5. OK, by the way the adabas*ui* part, which seems an extension, would remains? > >> Any suggestions? > > I wouldn't think too much about it for now; the idea is to keep the client > code in-tree (but disabled) so that if someone who needs it discovers it > isn't there anymore with 3.5, it can be reactivated quickly. Sounds reasonable to me. Cheers, -- Takeshi Abe > > -- > Francois Tigeot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice