Re: Contents of freebsd-questions Digest, Vol 123, Issue 19 ([PATCH] (/usr/lib/libxpg4.so.3 missing - Did I miss a memo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8JUtUn6S0hqD4tsRApolAKCoi93ZUsGgIhdzLD8IxyY6ZuEgygCbBGxw cggOIgfqSqJ2nIY/TVNKfKc= =Nh0n -END PGP SIGNATURE- diff -ru bacula-1.38.5-old/autoconf/configure.in bacula-1.38.5/autoconf/configure.in --- bacula-1.38.5-old/autoconf/configure.in Wed Dec 14 15:43:16 2005 +++ bacula-1.38.5/autoconf/configure.in Mon Feb 13 08:10:57 2006 @@ -1557,9 +1557,6 @@ # AC_FUNC_FNMATCHdnl use local version -dnl# FreeBSD needs to link libxpg4 -AC_CHECK_LIB(xpg4, setlocale, [LIBS=$LIBS -lxpg4]) -AC_CHECK_LIB(intl, gettext, [LIBS=$LIBS -lintl]) AC_CHECK_LIB(sun, getpwnam) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Contents of freebsd-questions Digest, Vol 123, Issue 19 ([PATCH] (/usr/lib/libxpg4.so.3 missing - Did I miss a memo?)
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
/usr/lib/libxpg4.so.3 missing - Did I miss a memo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Everything worked great until I built bacula-server-1.38.5_1. Package built fine. Installs and runs fine on all machines except the host that was originally installed from 6.0-RELEASE media. On that machine, the bacula daemons will not execute. They error with: (for example) /libexec/ld-elf.so.1: Shared object libxpg4.so.3 not found, required by bacula-dir This library does not exist on the from-6.0-install machine. I started by looking through /usr/src/UPDATING and can find no mention of this library on either the default branch or RELENG_5 branch. Next I started browsing through CVS and logs for /usr/src. Here's what I've found: This library has been obsolete and pretty much empty for a long time because its functionality was moved into libc. Yes, the library itself still existed up until the RELENG_5 tag. About 14 months ago, the files were removed on the mainline by tjr (Tim J. Robbins) on 2004-Nov-13. I've managed to get past this by adding a line to libmap.conf(5): libxpg4.so.3 libc.so.6 My questions (yes, finally) are: * Is this change documented somewhere that Google can't find or that I'm not looking? * Is my handling of this situation correct as a band-aid fix? * 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? * 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) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD7PFFUn6S0hqD4tsRApqfAJ0e28W6cWI+VR7bTYudh75wH0RrmACgrdxQ J846qPlquupb91uFcImU9JE= =pG2s -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/lib/libxpg4.so.3 missing - Did I miss a memo?
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. Kris pgpsSokSBMISh.pgp Description: PGP signature
