jd-boyd/python-lzo

Include lzo source code.

jd-boyd opened this issue · 4 comments

Based on how slowly the lzo c library is changed and the dependency issues that I keep hearing about, especially for windows and macos users, I'm thinking of just including the lzo c source in the published package to ease installation.

At the moment I'm just leaving that here to see if anyone comments on the idea. I don't know if anyone actually follows this closely enough to care.

I suppose that if the code is included it would still be a good idea to allow people to optionally specify an external lzo instead of using the included one.

I think that's a good idea and should work on any platform.

this is good idea since I have trouble install it with lzo-2.09 with 2.7.12

running build_ext
building 'lzo' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Walllzomodule.c: In function ‘optimize’:
lzomodule.c:304:5: warning: pointer targets in passing argument 1 of ‘PyString_FromStringAndSize’ differ in signgcc -pthread -shared -L/home/user/opt/lzo-2.09/lib build/temp.linux-x86_64-2.7/lzomodule.o -L/hpcf/apps/python/install/2.7.12/lib -llzo2 -lpython2.7 -o build/lib.linux-x86_64-2.7/lzo.so
hpcf/apps/python/install/2.7.12/include/python2.7/stringobject.h:62:24: note: expected ‘const char *’ but argument is of type ‘unsigned char *’
PyAPI_FUNC(PyObject *) PyString_FromStringAndSize(const char *, Py_ssize_t);
^
/usr/bin/ld: /home/user/opt/lzo-2.09/lib/liblzo2.a(lzo1x_9x.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/home/user/opt/lzo-2.09/lib/liblzo2.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
make: *** [all] Error 1

solved by

./configure --enable-shared

when install lzo-2.09. warning but installed...

With #60, the source is included. It isn't used for Linux (where package maintainers prefer to use the LZO2 packages), but it is used on Windows or MacOS unless LZO_DIR is overridden. However, it doesn't auto build lzo2 as part of setup.py, so for instance, in the test scripts, lzo2 is built first, then the setup.py is run.

Thus there is room for improvement, but this is technically done.