>>>>> On Wed, 28 Apr 2010 14:46:22 -0400, Steve Polyack said: > > On 04/28/10 14:15, Kern Sibbald wrote: > > I suspect that is something that we have seen before. If you explicitly add > > libraries (I suspect that you did, because Linker flags is set, which is > > not "normal"), Bacula could then link against previously installed libraries > > rather than its own library that it has just built, and you will get errors. > > > > Either don't use any Linker flags (as you have done), or deinstall the old > > Bacula and its shared libraries prior to building, or point linker flags to > > the Bacula build src/lib directory before pointing it to a directory where a > > previous version of Bacula is installed (in your case /usr/local/lib. > > > This is indeed the problem. I don't think that deinstalling the older > version of bacula first is a proper solution, though. I like the idea > of changing the order of the linker paths, however, I can't seem to find > where LDFLAGS is getting set. I think it's getting set by the configure > script, but I may be wrong. (It's set in the port Makefile, but > removing this declaration doesn't prevent it from getting set elsewhere.)
It must be set, so the linker can find other dependencies such as libpq that are always in /usr/local/lib on FreeBSD. I think there are two solutions for the port: 1) Put the libbac files in a private directory such as /usr/local/bacula/lib, which will not be on the linker path during make. Libtool takes care of relinking during make install. This is how it works in the "recommended" installation, which uses a separate directory for the whole of Bacula. 2) Turn off the shared libbac support with --disable-libtool. That will waste a few MB of disk space and memory but doesn't seem to cause any other problems. __Martin ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
