Path: csiph.com!usenet.pasdenom.info!gegeweb.org!newsfeed0.kamp.net!newsfeed.kamp.net!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.002 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'broken': 0.04; 'say,': 0.05; 'subject:Python': 0.06; 'binary': 0.07; 'matches': 0.07; 'executable': 0.09; 'subject:using': 0.09; 'subject:version': 0.09; 'used.': 0.09; 'wrapper': 0.09; 'python': 0.11; 'determines': 0.16; 'intended.': 0.16; 'itself,': 0.16; 'outdated': 0.16; 'reedy': 0.16; 'symbols': 0.16; 'sat,': 0.16; 'wrote:': 0.18; 'user.': 0.19; '>>>': 0.22; 'saying': 0.22; 'shell': 0.22; 'documented': 0.24; 'replace': 0.24; 'script.': 0.24; 'versions': 0.24; 'compiled': 0.26; 'this:': 0.26; 'header :In-Reply-To:1': 0.27; 'function': 0.29; 'am,': 0.29; 'patch': 0.29; 'thus': 0.29; 'message-id:@mail.gmail.com': 0.30; '>>>>': 0.31; 'ctypes': 0.31; 'table,': 0.31; 'file': 0.32; 'probably': 0.32; 'compatible': 0.32; 'another': 0.32; 'says': 0.33; '"the': 0.34; 'knowledge': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'add': 0.35; 'version': 0.36; 'really': 0.36; 'words,': 0.36; 'done': 0.36; 'subject:?': 0.36; 'should': 0.36; 'christian': 0.38; 'expected': 0.38; 'minimum': 0.38; 'version,': 0.38; 'to:addr:python-list': 0.38; '12,': 0.39; 'to:addr:python.org': 0.39; 'how': 0.40; 'even': 0.60; 'ian': 0.60; 'simple': 0.61; 'such': 0.63; 'become': 0.64; 'more': 0.64; 'different': 0.65; 'worth': 0.66; 'behavior': 0.77; 'opens': 0.91; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=A6HGOJF7ZCi8jQ1QxJ8ofTIF/l2VgGCDmObSHTHUTVI=; b=gDYDjc+27hBi+6p3dd7Y8cHnGA4ucliq3bYL3wYTdtpRZ0UGEFPatAl7FEe5emgV2q hA//Ga99Fx7ew45/Np4XZ/vU3jjayzEizfodbMFtAUaGOVYG5smUebXyGcosGHnFPWbJ 72WeP9zsQAGvxz85TVHIP+v7+uMrARyI4CcJxJjPFT29aXtIAYOn5C2q2JPcB9ywEAYA gMw2etrH/sz3dvxeCFoVeaVQ8rsLliZ/W/CFyJibbKTLIkZOpQv3vZUWymJic5x7/d9J WqsAtnzDu6EQ7QE/QouQhwAN655B2uiT2BwieOyYUrKwu7TrkmoQicr8N91ZiZAwdsGV AoAA== X-Received: by 10.66.11.202 with SMTP id s10mr29235306pab.86.1381609740563; Sat, 12 Oct 2013 13:29:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Ian Kelly Date: Sat, 12 Oct 2013 14:28:20 -0600 Subject: Re: What version of glibc is Python using? To: Python Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 37 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1381610118 news.xs4all.nl 15951 [2001:888:2000:d::a6]:60369 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:56757 On Sat, Oct 12, 2013 at 9:59 AM, Terry Reedy wrote: > On 10/12/2013 7:43 AM, Ian Kelly wrote: >> >> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy wrote: >>> >>> On 10/12/2013 3:53 AM, Christian Gollwitzer wrote: >>>> >>>> >>>> That function is really bogus. It states itself, that it has "intimate >>>> knowledge of how different libc versions add symbols to the executable >>>> and thus is probably only useable for executables compiled using gcc" >>>> which is just another way of saying "it'll become outdated and broken >>>> soon". It's not even done by reading the symbol table, it opens the >>>> binary and matches a RE *shocked* I would have expected such hacks in a >>>> shell script. >>>> >>>> glibc has a function for this: >>>> >>>> gnu_get_libc_version () >>>> >>>> which should be used. > > > Was this always presence and missed, or has it been added in say, the last > 10 years? Reading the docs more closely, I think that the function is actually working as intended. It says that it determines "the libc version against which the file executable (defaults to the Python interpreter) is linked" -- or in other words, the minimum compatible libc version, NOT the libc version that is currently loaded. So I think that a patch to replace this with gnu_get_libc_version() should be rejected, since it would change the documented behavior of the function. It may be worth considering adding an additional function that matches the OP's expectations, but since it would just be a simple ctypes wrapper it is probably best done by the user.