From owner-freebsd-questions@FreeBSD.ORG Wed May 21 18:49:01 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E75337B40F for ; Wed, 21 May 2003 18:49:01 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7682F43FBD for ; Wed, 21 May 2003 18:49:00 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4M1mxo3074776; Wed, 21 May 2003 20:48:59 -0500 (CDT) (envelope-from dan) Date: Wed, 21 May 2003 20:48:59 -0500 From: Dan Nelson To: Ralph Dratman Message-ID: <20030522014859.GA13024@dan.emsphone.com> References: <20030522002446.GE99691@webserver.get-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.1-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-questions@freebsd.org cc: Joshua Oreman Subject: Re: libintl.so.2 problems (REPOST: wrong subject and recipient) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 01:49:01 -0000 In the last episode (May 21), Ralph Dratman said: > So it appears that the particular shared object in question, > libintl.so.2, is not included in (this version of?) gettext. Find whatever port is trying to use libintl.so.2 and rebuild it too. ldd /usr/local/bin/* should help here. The portupgrade port makes it a cinch to do a force-rebuild of arbitrary ports. You won't be able to use binary packages on a userland as old as 4.2, but you should be able to compile whatever you need from ports. > There is an additional cryptic message I keep getting during builds, > which just might conceivably be relevant: > > /bin/realpath: not found I've been able to use the ports tree on a system with a 4.0(!) kernel and userland by rebuilding certain binaries from the base system as necessary. From a quick examination, it looks like I've only had to build newer versions of lib/libc, lib/libfetch, usr.bin/make, usr.sbin/pkg_install, bin/realpath, share/mk, and the files in etc/mtree. You can get away with not updating libc if you replace calls to getprogname() with __progname (prototype it as extern char *__progname). -- Dan Nelson dnelson@allantgroup.com