Issue #765 resolved

64 bit system giving 'wrong ELF class: ELFCLASS32' running Liquid within Octopress

neek
created an issue

I'm on a relatively fresh Fedora Core 16 64bit installation, that only had 64bit python installed when I came to install Octopress last week.

Having installed all required dependencies for Octopress, I got a 'undefined method `Py_IsInitialized’ for RubyPython::Python:Module' error message when generating a blog post that invoked the Pygment syntax formatter due to an embedded 'codeblock' in a blog post. To fix this, I discovered that it was looking in /usr/lib for the libpython2.7.so, and I only had one in /usr/lib64, because I only had the 64bit Python packages installed. I symlinked /usr/lib/libpython2.7.so to /usr/lib64/libpython2.7.so (yes, I know, urg) and the problem went away, Liquid ran successfully. I then removed my symlink and installed the 32bit packages with 'yum install python.i686' and the problem was still fixed, so I considered the problem sorted.

I'm now finding further errors. I think it only worked the other day because, in debugging the initial error, I had symlinked the 32 bit /usr/lib/libpython2.7.so to the 64 bit version, and that loaded library had stuck in memory, so my installation of the 32 bit version appeared to keep the fix but was in fact using the in-memory 64 bit library still. Now that I have rebooted, all libraries are being loaded fresh, and the 32 bit one I installed is causing problems.

I'm now getting:

{{{

!shell

Liquid error: Could not open library ‘/usr/lib/libpython2.7.so’: /usr/lib/libpython2.7.so: wrong ELF class: ELFCLASS32 }}}

So it seems that Pygments is, somehow, looking in /usr/lib instead of /usr/lib64 for its libraries. Now that it is indeed finding the 32bit library in /usr/lib, the linker is complaining that it's incompatible with the ELF class of the binary loading it.

My question is, is this a problem with Octopress's RVM setup in indicating which gems to use, or a Liquid configuration problem in knowing which libpython to link against, or a Python problem in some way?

If it is a Pygments problem, should I try rebuilding it somehow? I've no idea how it got installed. Is it part of the python RPM for Fedora, or did it come with the rubypython gem that RVM installed?

I sought some help on #rvm IRC channel the other day but couldn't really get any help.

My quick fix for now is to 'yum remove python.i686' and put my symlink back in with 'ln -s /usr/lib64/libpython2.7.so /usr/lib/libpython2.7.so' but this is clearly horrible and something else needs fixing.

Comments (2)

  1. neek reporter

    I thought I'd poke about and see where pygments is, and this is what seems to be on my system:

    [root@uberneek lib]# pygmentize -V
    Pygments version 1.4, (c) 2006-2008 by Georg Brandl.
    [root@uberneek lib]# which pygmentize 
    /usr/bin/pygmentize
    [root@uberneek lib]# rpm -qf /usr/bin/pygmentize 
    python-pygments-1.4-1.fc16.noarch
    

    The command I run to invoke ruby and pygments is:

    rake generate
    

    This kicks off the Octopress framework, which seems to be mostly Ruby. Somewhere in there, Pygments gets called. This may be directly, or via the rubypython gem, I've no idea. Perhaps you can shed some light on the way Pygments is being invoked and libpython2.7.so is being loaded. I've a strong feeling this problem has nothing to do with Pygments, it's a packaging or configuration problem in one of these other systems.

  2. Georg Brandl repo owner

    Sorry, after a short look I cannot see the reason for your problems. All I can say is that Pygments is a perfectly ordinary Python package and has no special behavior looking for libraries on its own.

    So if there is a bug as opposed to an installation/setup problem, it lies either with the library/application that invokes/uses pygments, or with Ruby or Python itself.

  3. Log in to comment