From owner-freebsd-hackers Fri Jan 9 23:59:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05500 for hackers-outgoing; Fri, 9 Jan 1998 23:59:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from TomQNX.tomqnx.com (ott-pm6-27.comnet.ca [206.75.140.187]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05459 for ; Fri, 9 Jan 1998 23:59:33 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0xqvog-00080TC; Sat, 10 Jan 1998 02:58:50 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: lib warning To: hackers@FreeBSD.ORG Date: Sat, 10 Jan 1998 02:58:50 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk I just found out the hard way that there is a quirk that will bite you if, like me, you have been updating existing systems for a while. Apparently, there are a few library modules that have regressed from .so versions to .a versions. It seems that the linker will always link in the older .so version if one exists at link time. This happened on my system with libcompat.a and a couple of gcc libraries. I only discovered it when I compiled a program using the ftok function which was not present in the older .so version of the libraries. It was a puzzle to figure out why the link failed. I recommend that you scan the dates on your libraries and remove all .so versions where there is a newer .a version as a safety precaution. You might have to relink certain other programs that used the wrong (outdated) library... Regards, Tom