Contents of freebsd-questions Digest, Vol 123, Issue 19 ([PATCH] (/usr/lib/libxpg4.so.3 missing - Did I miss a memo?)

[Dan Langille]

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