Develop Reference

ImageMagick: OSError: /lib/libc.so.6: version `GLIBC_2.XX' not found

I am working on an embedded linux system and try to get python-wand running...
But i am not able to install anything on this system so i included them in the lib folder of my application (this folder will be linked to the system).
Its not possible to update the glibc version of the system.
To test if its working i am using:
from ctypes import *
cdll.LoadLibrary('libMagickWand-6.Q16.so.6')
This will throw:
OSError: /lib/libc.so.6: version `GLIBC_2.17' not found (required by
../libMagickCore-6.Q16.so.6)
So is it possible to build ImageMagick with a different glibc version packed ?
I am new to compiling but this should work if i can change glibc only for ImageMagick.
Is it possible if i compile ImageMagick with a older version of glibc ?
Is the compiled code affected by the gcc / glibc version ?

Finally i got this running on my embedded system:
Get same glibc/eglibc version on the cross compile system.
Compile imagemagick with this glibc version.
Don't forget to install libpng for png support...
Note:
If you want to use imagemagick combined with ghostscript to convert
pdf -> images don't forget that ghostscript is licensed under AGPL and
you cannot use this in your product unless you are using the same license, or buy the license....

You may set the LD_LIBRARY_PATH to your path (./lib) before starting python.
If it's a headless system you may write a shell script besides your python script to set the variable right before starting the python and then start python. Then use that script in your autostart code.

Vim compiled with Python support but can't see sys version

I compiled the development version of Vim with both Python 2 and Python 3 support. The output of vim --version has +python/dyn and +python3/dyn in it. I ran the configure file with
g
./configure --enable-pythoninterp --enable-python3interp --with-python-config-dir=/usr/lib64/python2.7/config --with-python3-config-dir=/usr/lib64/python3.3/config --with-x --with-features=huge
However when I run :python import sys; print(sys.version) I get
E448: Could not load library function _PyArg_Parse_SizeT
E263: Sorry, this command is disabled, the Python library could not be loaded.
Why would this be? I found out because of YouCompleteMe stating that it requires Vim compiled with 2.x support.
Thanks

I had a similar issue on my Debian box. If you're using a Debian-based system, you will not be able to load both Python libraries simultaneously. That's why when you set --enable-python-interp and --enable-python3-interp they always load with the /dyn suffix.
If your vim plugins don't need both versions, you should just pick one of the versions and stick with it. The links below provide more info.
Explained by Debian maintainer
Vim Python Support
P.S. - In case you tried this on Windows as well, loading either Python version will work, so the /dyn isn't an issue there.

Python distutils not using correct version of gcc

I am trying to compile a package on Mac OSX 10.6.5. The package's install script relies on distutils. The problem is that the computer's default gcc is version 4.2 (I determined this by just running gcc --version in a terminal window) but when I run 'python setup.py build', I see from the output that the distutils is choosing gcc-4.0 instead of 4.2 This is a big problem because the code I am using require gcc >= 4.2. I do not have admin rights on this machine, so as a workaroud, I created some symlinks that send gcc-4.0 to gcc-4.2. The result is the code compiles, but the generated .so files do not work (when I try to import them in python, I get errors complaining about a missing init function in the shared object).
I have tried compiling this code on a different mac (10.6.6) and it works like a charm: distutils chooses 4.2 without being forced to do so and I can import the generated shared object without a problem. So, what I would like to do is to compile the code on my computer without having to do this symlink trickery...I just want distutils to choose 4.2 automatically as it should. I have tried taking the .so files that compile properly and transferring them to my computer, but that fails for a number of reasons (they are linked against libraries that are not present on my machine/are a different version that those installed).
Does anyone have any advice here?
Thanks,
Josh

To force distutils to use a separate compiler, you can redefine a few variables via the environment. First, find out what distutils is using as defaults:
>>> from distutils import sysconfig
>>> sysconfig.get_config_var('LDSHARED')
'gcc-4.0 -Wl,-F. -bundle -undefined dynamic_lookup'
>>> sysconfig.get_config_var('CC')
'gcc-4.0'
Next you need to redefine those, substituting in the version of gcc you'd like to use:
% LDSHARED="gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup" CC=gcc-4.2 \
/usr/bin/python setup.py build_ext
Keep in mind that the sysconfig defaults are pulled from the Makefile which was originally used to compile python, so fudging with them may produce unintended results:
>>> path = sysconfig.get_python_lib(plat_specific=1, standard_lib=1)
>>> os.path.join(path, 'config', 'Makefile')
'/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/Makefile'

Have you tried setting a custom CC environment variable?
CC=gcc-4.2 python setup.py build

You don't say which versions of Python you are using but chances are that the default Python on the machine you are using is not the Apple-supplied Python 2.6.1, more likely one installed from python.org. Try running the build script with /usr/bin/python2.6 which should be the Apple-supplied Python 2.6; that does use gcc-4.2.
When you use Python's Distutils (typically by running a setup.py script or using easy_install), Distutils tries to make sure that any C extension modules in the package you are installing will be compiled with the same compiler version and with compatible compilation options (CPU archs, ABI, etc) as was used to build Python itself. Traditionally, most python.org installers for OS X provide a universal Python that works on multiple versions of OS X and multiple CPU archs. That's why they are built with gcc-4.0. If you need to use gcc-4.2 for some other library, then the safest thing is to use a Python that was built with gcc-4.2. The Apple-supplied system Pythons on OS X 10.6 are so built. Also, for the most recent releases of Python (2.7.1 and 3.2), python.org provides a second OS X installer variant for OS X 10.6 that is also built with gcc-4.2. But if you do not have admin access to your machine, that's not an option anyway.
You can see which python is being used by default by:
which python

You can either adjust your distutils.cfg (see here) or you can pass command line arguments as --compiler=gcc42 (not sure about the last one).

Install Trac on 64bits Windows 7

I'm configuring a new Developing Server that came with Windows 7 64bits.
It must have installed Trac with Subversion integration.
I install Subversion with VisualSVN 2.1.1, clients with TortoiseSVN 1.6.7 and AnkhSVN 2.1.7 for Visual Studio 2008 SP1 integration.
All works fine! my problem begun when going to Trac installation.
I install python 2.6 all fine.
Trac hasn't a x64 windows installer, so I installed it manually by compiling it with python console (C:\Python26\python.exe C:/TRAC/setup.py install).
After that, I can create TRAC projects normally, the Trac core is working fine. And so the problem begins, lets take a look at the Trac INSTALL file:
Requirements
To install Trac, the following software packages must be installed:
Python, version >= 2.3.
Subversion, version >= 1.0. (>= 1.1.xrecommended)
Subversion SWIG Python bindings (not PySVN).
PySQLite,version 1.x (for SQLite 2.x) or version 2.x (for SQLite 3.x)
Clearsilver, version >= 0.9.3 (0.9.14 recommended)
Python: OK
Subverion: OK
Subversion SWIG Python bindings (not PySVN):
Here I face the first issue, he asks me for 'cd' to the swig directory and run the 'configure' file, and the result is:
C:\swigwin-1.3.40> c:\python26\python.exe configure
File "configure", line 16
DUALCASE=1; export DUALCASE # for MKS sh
^
SyntaxError: invalid syntax
PySQLite, version 1.x (for SQLite 2.x) or version 2.x (for SQLite 3.x):
Don't need, as Python 2.6 comes with SQLLite
Clearsilver, version >= 0.9.3 (0.9.14 recommended):
Second issue, Clearsilver only has 32bit installer wich does not recognize python installation (as registry keys are in different places from 32 to 64 bits).
So I try to manually install it with python console. It returns me a error of the same kind as SWIG:
C:\clearsilver-0.10.5>C:\python26\python.exe ./configure
File "./configure", line 13
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
^
SyntaxError: invalid syntax
When I simulate a web server using the "TRACD" command, it runs fine when I disable svn support but when I try to open the web page it shows me a error regarding ClearSilver is not installed for generating the html content.
AND (for making me more happy) This TRAC will run over IIS7, I mustn't install Apache...
I'm nearly crazy with this issue... HELP!!!

Just export Register from [HKEY_LOCAL_MACHINE\SOFTWARE\Python] to [HKEY_CURRENT_USER\Software\Python].
It's happens because trac only see the [HKEY_CURRENT_USER\Software\Python] and you installed the python "For all users"

I would expect that Trac on Windows instructions should work on x64, even if they're 32-bit packages. Have you tried this and failed?
Subversion SWIG Python bindings:
configure is not meant to be run by Python; it's meant to be run with a POSIX sh, like Bash or ksh. However, if you read subversion/bindings/swig/INSTALL you'll find that the installation instructions for Windows do not use configure; instead, Visual Studio and gen-make.py are used.
Note that your bindings should match your installed Subversion.
Clearsilver:
Likewise, configure is meant for a sh, not Python. Clearsilver compilation instructions for Windows can be found in clearsilver/python/README.txt.

Looks like I'm not the only one trying to install Trac on Win 7 64-bit, only to see the install crash and burn.
One problem is the lack of installed registry entries for Python on Win x64, which I was able to find via a web search. The problem was identified months ago, but unfortunately no patch release has been made available.
I was almost ready to give up on Trac, but the information here has given me new hope. Thanks all!

How do I satisfy a 3rd-party shared library reference to stat when I'm creating a shared library shim rather than an executable?

I am the new maintainer for an in-house Python system that uses a set of 3rd-party shared C libraries via a shared library shim that is created using a combination of swig and a setup.py script. This has been working well until recently.
The 3rd-party shared C libraries were updated for new functionality and now I get the following run-time error, after a clean build, when I try to run our main Python program (which imports the generated shared library shim):
-sh-3.00$ python ams.py
ImportError: /usr/lib/libz4lnx.so: undefined symbol: stat
I found a discussion thread from 1999 that explains that the problem is that stat is not present in libc.so.6, but rather in libc_nonshared.a, and provides a solution: Link against the c library, by adding -lc to your build command line.
http://www.redhat.com/archives/pam-list/1999-February/msg00082.html
I've added 'c' to the list of libraries in the setup.py script, but this doesn't change my results. I suspect that this is because I am creating a shared library shim rather than an executable.
How can I satisfy the 3rd-party shared library's reference to stat, given my build environment?
My build system is:
-sh-3.00$ lsb_release -a
LSB Version: :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch
Distributor ID: CentOS
Description: CentOS release 4.6 (Final)
Release: 4.6
Codename: Final
My gcc version is:
-sh-3.00$ gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-10)
My Python version is:
-sh-3.00$ python -V
Python 2.3.4

The solution was to create to a new Centos 5.3 VM and re-build and/or re-install components as needed.

As it turns out, while moving to Centos 5.3 was probably a good thing in the long run, the actual problem turns out to have been the way that libz4lnx was built on the DVD that I was originally using. In the process of moving to Centos 5.3, I also moved to a newer build of the libz4lnx library. Today, while testing something else, I used the library from the original DVD and got the exact same undefined symbol error when running the Python program. Switching back to the newest DVD (some two months newer) solved the problem again.