From owner-freebsd-questions Wed Aug 15 10:45: 3 2001 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-27-141-144.mmcable.com [24.27.141.144]) by hub.freebsd.org (Postfix) with SMTP id F3E3A37B40A for ; Wed, 15 Aug 2001 10:44:56 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 97085 invoked by uid 100); 15 Aug 2001 17:44:55 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.46359.749829.315002@guru.mired.org> Date: Wed, 15 Aug 2001 12:44:55 -0500 To: Cc: questions@freebsd.org Subject: Re: managing libraries In-Reply-To: <25199823@toto.iv> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG joup@bigfoot.com types: > Is there any sort of general advice one should follow when dealing with > multiple versions of libraries? For instance, it seems like there are > plenty of symbolic *.so links to the most up-to-date *.so.# file, but most > applications tend to specify a specific number. (Is there a reason for > this?) Yes, there's a reason that libraries link to a specific number. It's to make sure the binary uses the version of the library that works, as opposed to one that may have a different ABI, and thus fail in unexpected ways. Generally, this happens when the binary is linked, and the number isn't specified by the application author. > My particular trouble tonight was a libGL.so.1 file that was referencing > several undefined pthread functions-- I found the pthread library, added > it to my $ldconfig_paths in rc.conf, reran ldconfig -R, and tried the > build again (qt-linguist). Same error. I finally mv'ed libGL.so.1 to a > backup file, made a symbolic link to libGL.so in its place (which in turn > points to libGL.so.14). > > Am I going to have problems later on because of this? Is there something > else I can do that isn't so kludgy? Something very strange is going on here. Where did you get libGL.so.14? I've just got libGL.so.1. Second, how much did you clean before trying the build again? In particular, did you rerun the config, making sure not to use any old values? It's normal for a config to snoop library files to figure out what functions are available, so changing the library used may well change the configuration for the program. Normally, the include files used for the compile and the library are paired, and changing the library is asking for problems. Do you know whether the include files used by programs that want to use libGL.so are the ones that go with .1, or .14? That will make a difference. Oh, that general advice you asked for - try to avoid it. Rebuild binaries to use the latest version when you update libraries across a version number. If you can't do that, keep both versions around, but make sure the versionless symlinks point to the version described by the include files installed on the system. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message