Version: 3.0 alpha7 (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 2.95.4 20020320 [FreeBSD] OS: FreeBSD Background: on FreeBSD one can have several installations of Berkeley DB libraries. In the base system, there's the ancient 1.85 version. Other versions installed by the portscollection have their library and header location renamed to avoid conflicts. The patch attached shortly fixes build problems on FreeBSD. To build correctly the appropreate values for db-dir and db-name need to be given. Ports maintainers will easily be able to pick this up. As a quick-fix I've added the inclusion of config.h on lib/catalog/gcatalog.h because several files seem to include it, before config.h is included leaving an undefined type for DB. As a side note it fixes the install target on Bourne type shells.
Created attachment 2693 [details] Berkeley DB compatibility
Patch looks ok, and I believe there's even one more version of db available now as a port. Unfortunately I'm not in a position to test or experiment. Melvyn, you may want to send a message to kde@freebsd, to see if there's someone there with a kdevelop that can be experimented with.
The patch looks good, but why did you put the check into configure.in.in instead of kdevelop.m4.in with the rest of the checks? I'd rather have the ugly parts in kdevelop.m4.in so that configure.in.in is readable. Harry
I'm sure it doesn't make any difference as long as the same result is achieved. So if you want to do it that way, I don't think the reporter would have any objections.
Subject: Re: [PATCH] Build fix for alternate DB3/4 installations On Sunday 04 January 2004 07:22, you wrote: > ------- Additional Comments From will@csociety.org 2004-01-04 07:21 > ------- I'm sure it doesn't make any difference as long as the same result > is achieved. So if you want to do it that way, I don't think the reporter > would have any objections. IIRC I tried first in kdevelop.m4 but that didn't work. I haven't chased the cause, but it had something to do with the availablity of certain macro's. If you can get it working, of course I have no objections.
This is fixed in HEAD