Date: Mon, 13 Feb 2006 09:36:34 -0500 From: "Dan Langille" <dan@langille.org> To: Trix Farrar <trix@basement.net> Cc: freebsd-questions@freebsd.org Subject: Re: Contents of freebsd-questions Digest, Vol 123, Issue 19 ([PATCH] (/usr/lib/libxpg4.so.3 missing - Did I miss a memo?) Message-ID: <43F05322.28188.FC956F2@dan.langille.org> In-Reply-To: <43F09534.3040506@basement.net> References: <20060210212539.31C8E16A420@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Feb 2006 at 8:18, Trix Farrar wrote: > On Fri, 10 Feb 2006 15:37:56 -0500, Kris Kennaway wrote: > > > On Fri, Feb 10, 2006 at 02:02:17PM -0600, Trix Farrar wrote: > >> > On my network, I have several hosts that were originally installed with > >> > FreeBSD 5.2.1-RELEASE, 5.3-RELEASE, and 5.4-RELEASE. All of these have > >> > been updated now to 6.0-RELEASE-p4. One host was originally installed > >> > from 6.0-RELEASE media and subsequently updated to p4. All works well. > >> > > >> > I took a cue from The FreeBSD Handbook; 21.5 Tracking for Multiple > >> > Machines, and have a central build host for the network. On this > >> > machine, I do my make buildworld, make buildkernel and building of > >> > packages to ports. That way I can just install port packages on the > >> > non-build machine. > > > > If you do this, you need to make sure you're generating compatible > > binaries. In this case, you seem to be generating binaries that are > > targetted for an older release than FreeBSD 6.0. In order to run 5.x > > binaries on FreeBSD 6.0, you need to install the compat5x port and > > build with the corresponding kernel option. > > > >> > * How can I know whether or not it is save to delete libxpg4.a, > >> > libxpg4.so, libxpg4.so.3, and libxpg4_p.a from /usr/lib on the machines > >> > where they are present? > > > > Use the libchk port. > > > >> > * Why would bacula (or anything else, for that matter) even try to link > >> > to this library in the first place? (Ok, I'll admit that I'm being lazy > >> > on this one because I haven't really researched it yet) > > > > I'm guessing you are running an old 5.x binary from before the > > removal. A 6.0 binary of bacula indeed will not try to link to this > > nonexistent library. > > > > I think I found the answer, at least as it relates to Bacula: > > libxpg4.so.3 used to be built up until FreeBSD 5.4, so a system that was > originally installed before 6.0 would have that library lying around > because it doesn't get deleted in the process of upgrading to/through > 5.0-RELEASE. 6.0 systems, no longer have the source for this library > (because it has been a dummy to satisfy link dependencies for some > time), so it is no longer built or installed. > > Bacula's configure.in script specifically adds a link to libxpg4 as part > of the build processes - - even though there are no functions to call in > this library. > > On a 6.0 system, this would silently fail and all would be well. On > pre-6.0 system, this would silently succeed and all would be well. It's > when you try to cross systems that problems pop up. > > By applying the attached patch (which deletes 3 lines from > autoconf/configure.in), the entire issue goes away. > > Would this be an issue for a PR or just a note to the Bacula developers? > The lines I propose to delete are commented as a FreeBSD-specific hook. We could add it a patch for the port in the short term, but pass it along to the Bacula project as well. -- Dan Langille : Software Developer looking for work my resume: http://www.freebsddiary.org/dan_langille.php
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F05322.28188.FC956F2>