public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Joshua Murphy" <poisonbl@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] A question about emerge --info
Date: Wed, 29 Oct 2008 20:47:41 -0400	[thread overview]
Message-ID: <c30988c30810291747k20c7841cveb542d0356ebc91f@mail.gmail.com> (raw)
In-Reply-To: <e38d12ff0810291651y245cba2k89b9cb2b8ee39dd9@mail.gmail.com>

On Wed, Oct 29, 2008 at 7:51 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
<snip>
>    elif system in ('Linux',):
>        # Linux based systems
>        distname,distversion,distid = dist('')
>        if distname and not terse:
>            platform = _platform(system,release,machine,processor,
>                                 'with',
>                                 distname,distversion,distid)
>        else:
>            # If the distribution name is unknown check for libc vs. glibc
>            libcname,libcversion = libc_ver(sys.executable)
>            platform = _platform(system,release,machine,processor,
>                                 'with',
>                                 libcname+libcversion)
<snip>

Hrm. I know just enough about python to get myself in trouble here...
but it looks like a python bug in magicking up the libc name and
version... but the below is WAY outside my level of practice with
python (it'll take re-reading and digging elsewhere a good few times
if I'm ever to make sense of it...

------------------
def libc_ver(executable=sys.executable,lib='',version='',

             chunksize=2048):

    """ Tries to determine the libc version that the file executable
        (which defaults to the Python interpreter) is linked against.

        Returns a tuple of strings (lib,version) which default to the
        given parameters in case the lookup fails.

        Note that the function has intimate knowledge of how different
        libc versions add symbols to the executable and thus is probably
        only useable for executables compiled using gcc.

        The file is read and scanned in chunks of chunksize bytes.

    """
    f = open(executable,'rb')
    binary = f.read(chunksize)
    pos = 0
    while 1:
        m = _libc_search.search(binary,pos)
        if not m:
            binary = f.read(chunksize)
            if not binary:
                break
            pos = 0
            continue
        libcinit,glibc,glibcversion,so,threads,soversion = m.groups()
        if libcinit and not lib:
            lib = 'libc'
        elif glibc:
            if lib != 'glibc':
                lib = 'glibc'
                version = glibcversion
            elif glibcversion > version:
                version = glibcversion
        elif so:
            if lib != 'glibc':
                lib = 'libc'
                if soversion > version:
                    version = soversion
                if threads and version[-len(threads):] != threads:
                    version = version + threads
        pos = m.end()
    f.close()
    return lib,version
------------------

It parses the header of an executable and guesses, but... the how is
too many directions from this that I'm not seeing it with my haphazard
abuse of grep. I'd presume anything that might care what platform it's
running on (underneath python itself) would be susceptible, so a word
thrown in the direction of upstream python would be the main way to
go... though it looks like emerge didn't used to use that call...

Portage 2.1.4.5 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0,
2.6.25-gentoo-r7-mahain i686)
=================================================================
System uname: 2.6.25-gentoo-r7-mahain i686 AMD Athlon(tm) MP 2400+

is my output, based on a call in emerge to "uname -mrp" .. not
platform.platform()

Looks like gentoo-dev aimed to drop that dependency in newer versions after all.

-- 
Poison [BLX]
Joshua M. Murphy



  parent reply	other threads:[~2008-10-30  0:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-29 22:53 [gentoo-user] A question about emerge --info Paul Hartman
2008-10-29 23:06 ` Andrey Vul
2008-10-29 23:09 ` Andrey Falko
2008-10-29 23:13   ` Andrey Vul
2008-10-29 23:23     ` Andrey Falko
2008-10-29 23:32       ` Andrey Vul
2008-10-29 23:41         ` Andrey Vul
2008-10-29 23:51           ` Andrey Vul
2008-10-29 23:57             ` Andrey Falko
2008-10-30  0:03               ` Andrey Vul
2008-10-30  0:15                 ` Andrey Falko
2008-10-30  0:26                   ` Andrey Vul
2008-10-30  2:02                   ` Andrey Vul
2008-10-30 10:37                     ` Geralt
2008-10-30  1:49                 ` Paul Hartman
2008-10-30  0:47             ` Joshua Murphy [this message]
2008-10-30  1:30               ` Andrey Vul
2008-10-30  1:31               ` Andrey Vul
2008-10-30 12:26               ` Albert Hopkins
2008-10-30 12:43                 ` Heiko Wundram
2008-10-30 13:44                   ` Albert Hopkins
2008-10-29 23:21   ` Paul Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c30988c30810291747k20c7841cveb542d0356ebc91f@mail.gmail.com \
    --to=poisonbl@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox