On Wednesday 05 September 2007 21:39, Eric Bollengier wrote: > Hi, > > I'm running a debian etch system, and > on my system i have a /usr/lib64 which is empty, and when i use > --with-sqlite3, batch mode is disabled with the following error : > > checking for SQLite3 support... yes > checking for SQLite support... no > nm: '/usr/lib64/libsqlite3.a': No such file > > .. > > Batch insert enabled: no > > The file autoconf/bacula-macros/db.m4 is doing this : > > SQLITE_INCDIR=/usr/local/include > if test -d /usr/local/lib64; then > SQLITE_LIBDIR=/usr/local/lib64 > else > SQLITE_LIBDIR=/usr/local/lib > fi > > It doesn't check if /usr/xxx/lib64 contains the library, in my case, > this directory is empty... > > Do you think that we can use something like test -f > /usr/xxx/lib/libsqlite.a instead of test -d /usr/xxx/lib ?
Yes, of course we can fix it. Indeed when I was programming the 64 bit tests, I noticed this problem. However, there are way more things than I can possibly do. Making changes such as that take a *huge* amount of time to implement and test, and all because of a directory that should not be there. So, I'll be happy to accept a patch, provided it is *very* well tested under all kinds of circumstances. Personally, I think it far easier to delete such directories A /usr/local/lib64 (IMO) should exist only on a 64 bit machine and should be populated. > > Bye > > On Tuesday 04 September 2007 11:56:30 Kern Sibbald wrote: > > Hello, > > > > Now that we have just released version 2.2.1, as Murphy's law dictates, > > we have a couple of more important bugs that seem to affect only older > > systems. > > > > One is a problem building with older PostgreSQL versions > > The other is a Director critical crash caused by new code that supports > > certain older "brain damaged" OSes (including Win32). > > > > Note: the above problems only affect a small number of systems. Any > > recent version of Linux, Solaris, FreeBSD should have no problems. > > > > Normally, I would just release a couple of patches, but the problem > > affects the current Win32 Bacula servers, so we *must* release a new > > Win32 binary. > > > > Bottom line: I'm very likely going to make a release of version 2.2.2 at > > least for Win32, and either a patch or a full release for the source > > code. > > > > IMO, there is no reason to make new releases of the rpms unless one of > > the released rpms fails, which I think is unlikely. > > > > Question: does anyone feel that the 2.2.2 release should have anything > > other than Eric's PostgreSQL configure fix, my Director crash fix, and > > Scott's new .spec files (already committed)? > > > > Regards, > > > > Kern > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Bacula-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
