From owner-freebsd-ports Thu Apr 10 18:33:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA17888 for ports-outgoing; Thu, 10 Apr 1997 18:33:05 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA17883 for ; Thu, 10 Apr 1997 18:33:02 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA07928; Fri, 11 Apr 1997 11:02:55 +0930 (CST) From: Michael Smith Message-Id: <199704110132.LAA07928@genesis.atrad.adelaide.edu.au> Subject: Re: detecting shared lib versions In-Reply-To: from Chuck Robey at "Apr 10, 97 08:38:40 am" To: chuckr@glue.umd.edu (Chuck Robey) Date: Fri, 11 Apr 1997 11:02:54 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, ports@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chuck Robey stands accused of saying: > > > > Now, I can write a RUN_DEPENDS rule that depends on a _particular_ > > libc version (ie. a specific file), but what I need is a way to handle > > shared-library-like numbering on libraries that aren't managed by > > ldconfig (a regexp like like LIB_DEPENDS would probably do it). > > > > Failing that, it's Tcl time 8) > > > > locate_compatShlib linux libc 5.4.4 -greaterok > > Back when I did the first kaffe port, it depended on a specific version of > the jdk being at a specific spot. I think that's congruent to your > problem, since the linux libs are restricted to a specific name/spot also. > I just had a short script that did an md5 on the jdk and compared the > return with a stored value (I think in ${FILESDIR}/classes.zip.1.02.md5}. > If it failed the check, it printed an error message and quit. Would this > work for you? No; maybe I wasn't clear about what I want - I have a port that requires "at least version 5.4.4" of the Linux libc. The 2.3 linux_lib port contains libc.so.5.3.12, which is symlinked by the linux 'ldconfig' as 'libc.so.5'. The most current libc erich could find was libc.so.5.4.23, which works fine. In some future time, another linux_lib distribution is likely to contain yet another libc version; it would be nice not to have to 'fix' the StarOffice port at that point to require the new library, ie. it should be happy with "anything" later then 5.4.4. For now, I think I'll just depend on the soon-to-be-committed linux_lib-2.4 libc and worry about it if/when things change next time. Off to commit the monster. Do I get marks for 'big' ports? 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[