search

google-code-export / pymssql

Automatically exported from code.google.com/p/pymssql
GNU Lesser General Public License v2.1
0 stars 0 forks source link

"undefined symbol: __vasprintf_chk" on some CentOS, RedHat because of precompiled FreeTDS Linux library #71

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Thought I'd share these warnings:

cythoning _mssql.pyx to _mssql.c
warning: _mssql.pyx:1198:51: local variable 'data' referenced before
assignment
warning: _mssql.pyx:170:11: Unreachable code

cythoning pymssql.pyx to pymssql.c
warning: pymssql.pyx:410:8: Unreachable code

Original issue reported on code.google.com by rizw...@gmail.com on 19 Oct 2011 at 1:06

GoogleCodeExporter commented 9 years ago 
I have reproduced these in CentOS6

Resulting in:

ImportError: 
.../venv/lib/python2.7/site-packages/pymssql-2.0.0b1_dev_20111019-py2.7-linux-x8
6_64.egg/_mssql.so: undefined symbol: __vasprintf_chk

Original comment by Capt.Saf...@gmail.com on 18 Nov 2011 at 5:16

GoogleCodeExporter commented 9 years ago 
Capt.Safety: are you sure the warnings are related to your import error?  That 
seems highly unlikely to me.  I have the errors when I build and can import 
just fine.  It seems more likely that the way I am building the binary file 
works on Ubuntu but not CentOS.  I don't do much with C, so I am not 
immediately sure how to solve the import problem you are having.  However, can 
you please post your import error as a new issue so it can be tracked 
separately.

Original comment by rsyr...@gmail.com on 18 Nov 2011 at 8:23

GoogleCodeExporter commented 9 years ago 
Yes in fact when I started digging it was clear that the warnings are 
unrelated. As for the other issue I am going to try to track down additional 
info.

Original comment by Capt.Saf...@gmail.com on 18 Nov 2011 at 8:40

GoogleCodeExporter commented 9 years ago 
I am getting the same issue as Capt.Safety:

On CentOS 5.7:

ImportError: 
.pythonbrew/pythons/Python-2.7.2/lib/python2.7/site-packages/_mssql.so: 
undefined symbol: __vasprintf_chk

Original comment by vsunkava...@gmail.com on 10 Dec 2011 at 6:24

GoogleCodeExporter commented 9 years ago 
I am getting the same issues in RedHat 2.6.18-194.17.1.el5. I got no errors 
during the build but I can't use the module and I have no clue what's wrong:

$ python26
Python 2.6.5 (r265:79063, Jun  4 2010, 21:42:56) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pymssql
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_mssql.pxd", line 10, in init pymssql (pymssql.c:8589)
ImportError: 
/usr/lib64/python2.6/site-packages/pymssql-2.0.0b1_dev_20111019-py2.6-linux-x86_
64.egg/_mssql.so: undefined symbol: __vasprintf_chk

Original comment by charl...@unixrealm.com on 17 Jan 2012 at 8:00

GoogleCodeExporter commented 9 years ago 
I've run into this same issue on CentOS 5.5

Original comment by kai5263499 on 19 Jan 2012 at 7:44

GoogleCodeExporter commented 9 years ago 
Reporting this for Cent OS 5.7, too.

Original comment by Jordan.B...@gmail.com on 10 Feb 2012 at 3:45

GoogleCodeExporter commented 9 years ago 
Deleting the embedded freetds directory enables linking to freetds from the 
platform. The __vasprintf_chk symbol does not exist in libc on all platforms, 
but the embedded freetds appears to depend on it.

Original comment by jeremy.m...@gmail.com on 15 Feb 2012 at 2:44

GoogleCodeExporter commented 9 years ago 
Could you please elaborate a bit on how to solve this issue?

Original comment by Albin.St...@gmail.com on 18 Feb 2012 at 10:43

GoogleCodeExporter commented 9 years ago

Original comment by rsyr...@gmail.com on 8 Mar 2012 at 2:50

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Here is what our own sysadmin was able to do from clues provided by jeremy.m in 
comment 8 to get it working on our RHEL5 w/python 2.7.2. I hope it helps 
someone else...

"When you download the package, it's a compressed tar ball. When you expand it, 
it goes into a folder (pymssql-2.0.0b1-dev-20111019) with a bunch of 
sub-folders. One of those sub-folders was "freetds". All I did was a "rm -rf 
freetds" and then a "python setup.py build" and a "python setup.py install" and 
I was done. (Of course I could have done this all with just the one "install" 
command but I'm a little careful of things.)"

Original comment by r...@mbari.org on 9 May 2012 at 4:14

GoogleCodeExporter commented 9 years ago 
I think it's nice that the packager have chosen to ship pre-compiled FreeTDS 
libraries, but these are getting increasingly incompatible with more recent 
systems.

Perhaps you could remove the freetds directory from the tarball and distribute 
it separately for people who cannot easily get FreeTDS compiled on their 
systems.

Original comment by LeoRoch...@gmail.com on 30 Nov 2012 at 5:53

GoogleCodeExporter commented 9 years ago 
I agree with comment 14. I think shipping pre-compiled FreeTDS libraries is 
pretty weird and is going to cause obscure problems like this one and 
https://groups.google.com/forum/m/?fromgroups#!topic/pymssql/ATUmhyeaCbo (Mac 
OS X was trying to link with these libraries and failing).

Instructions for building FreeTDS I think are better than bundling binaries.

Or even a [buildout](http://www.buildout.org/) recipe to build FreeTDS? Hmmm, I 
might take a stab at that...

Original comment by msabr...@gmail.com on 1 Dec 2012 at 6:12

GoogleCodeExporter commented 9 years ago 
Note that an alternative to putting a bunch of logic in `setup.py` for 
detecting all of the possible places that FreeTDS could be (e.g.: /opt/local 
for MacPorts, /sw for Fink, /usr/local for Homebrew, ./freetds/nix_64 for Linux 
64 bit), one could leave the burden on the user to specify which FreeTDS to use 
-- e.g.:

CFLAGS="-I./parts/freetds/include" LDFLAGS="-L./parts/freetds/lib" python setup.py build

Original comment by msabr...@gmail.com on 1 Dec 2012 at 8:52

GoogleCodeExporter commented 9 years ago 
Another example of a problem that occurs because of including the FreeTDS 
binaries in pymssql: http://code.google.com/p/pymssql/issues/detail?id=97

Original comment by msabr...@gmail.com on 2 Dec 2012 at 5:52

GoogleCodeExporter commented 9 years ago 
See message here for suggested fix for OSX: 
https://groups.google.com/forum/?fromgroups=#!topic/pymssql/lJZmNNg90RQ

Original comment by rsyr...@gmail.com on 2 Jan 2013 at 10:12

GoogleCodeExporter commented 9 years ago 
IMO, we shouldn't try to add more libraries, like these OSX ones, into the 
pymssql distribution.

These libraries are bound to become obsolete one day and cause problems that 
are very hard to debug and understand, like the current ImportErrors or even 
segfaults.

Instead we should remove *all* these pre-compiled libraries and rely on the 
standard distutils mechanism for finding the FreeTDS headers/libraries 
elsewhere on the system.

Additionally, we could provide separate distributions for these pre-compiled 
libraries, with clear instructions on how to use them by passing standard 
distutils flags or environment variables.

Original comment by LeoRoch...@gmail.com on 3 Jan 2013 at 12:37

GoogleCodeExporter commented 9 years ago 
The original problem here was a specific undefined symbol error ("undefined 
symbol: __vasprintf_chk") on CentOS and RedHat systems.

Some of us, including myself, went off on a tangent and mentioned OS X, but I 
thought that maybe we should rename this issue to reflect the specific CentOS 
and RedHat error that was originally reported. This error is not fixed, but a 
workaround is to delete the bundled FreeTDS Linux library.

I think the problem is that the FreeTDS library was built on a modern Linux 
system with a fairly recent version of libc and that libc has __vasprintf_chk 
defined:

vagrant@lucid64:~/dev/hg-repos/pymssql$ ldd pymssql.so | grep libc libc.so.6 => /lib/libc.so.6 (0x00007ff2c5f1a000) vagrant@lucid64:~/dev/hg-repos/pymssql$ nm -D /lib/libc.so.6 | grep vasprintf_chk 00000000000feb30 T __vasprintf_chk


These CentOS and RedHat systems probably use an older version of libc which 
doesn't have this symbol. I bet that it the folks on these system run the 
commands above, they will find no __vasprintf_chk symbol in their libc.so

As LeoRochael mentions, it may be best to remove the bundled FreeTDS libraries, 
as it is difficult to maintain a set of libraries that works on all systems.

Original comment by msabr...@gmail.com on 9 Jan 2013 at 7:08

GoogleCodeExporter commented 9 years ago 
In my case on RHEL 5.9  2.6.18-348.3.1.el5 it did not work to remove freetds 
dir from under pymssql-2.0.0b1../

instead I changed the setup.py script to include libs from /usr/lib64 which 
seems to have done the trick for me

    library_dirs = [
        '/usr/lib64'
        #os.path.join(FREETDS, 'lib')
    ]

Original comment by davideag...@gmail.com on 20 Mar 2013 at 12:00

GoogleCodeExporter commented 9 years ago 
on RHEL 5.4 2.6.18-164.el5

 library_dirs = [
        '/usr/lib64'
        #os.path.join(FREETDS, 'lib')
    ]
does not work

Original comment by hk.y...@gmail.com on 9 May 2013 at 5:39

GoogleCodeExporter commented 9 years ago

Original comment by msabr...@gmail.com on 7 Aug 2013 at 2:04

GoogleCodeExporter commented 9 years ago

Original comment by msabr...@gmail.com on 7 Aug 2013 at 3:17

GoogleCodeExporter commented 9 years ago 
I could not reproduce this on CentOS 6.3, presumably because it has a new 
enough libc. It has glibc 2.2.5.

[marca@localhost pymssql]$ python setup.py build_ext -i setup.py: platform.system() => 'Linux' setup.py: platform.architecture() => ('64bit', 'ELF') setup.py: platform.linux_distribution() => ('CentOS', '6.3', 'Final') setup.py: platform.libc_ver() => ('glibc', '2.2.5') setup.py: Using bundled FreeTDS in /home/marca/dev/hg-repos/pymssql/freetds/nix_64 setup.py: include_dirs = ['/home/marca/dev/hg-repos/pymssql/freetds/nix_64/include', '/usr/local/include'] setup.py: library_dirs = ['/home/marca/dev/hg-repos/pymssql/freetds/nix_64/lib', '/usr/local/lib'] running build_ext cythoning _mssql.pyx to _mssql.c building '_mssql' extension creating build/temp.linux-x86_64-2.6 gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/marca/dev/hg-repos/pymssql/freetds/nix_64/include -I/usr/local/include -I/usr/include/python2.6 -c _mssql.c -o build/temp.linux-x86_64-2.6/_mssql.o -DMSDBLIB gcc -pthread -shared build/temp.linux-x86_64-2.6/_mssql.o -L/home/marca/dev/hg-repos/pymssql/freetds/nix_64/lib -L/usr/local/lib -L/usr/lib64 -lsybdb -lrt -lpython2.6 -o /home/marca/dev/hg-repos/pymssql/_mssql.so cythoning pymssql.pyx to pymssql.c building 'pymssql' extension gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/marca/dev/hg-repos/pymssql/freetds/nix_64/include -I/usr/local/include -I/usr/include/python2.6 -c pymssql.c -o build/temp.linux-x86_64-2.6/pymssql.o -DMSDBLIB gcc -pthread -shared build/temp.linux-x86_64-2.6/pymssql.o -L/home/marca/dev/hg-repos/pymssql/freetds/nix_64/lib -L/usr/local/lib -L/usr/lib64 -lsybdb -lrt -lpython2.6 -o /home/marca/dev/hg-repos/pymssql/pymssql.so [marca@localhost pymssql]$ python Python 2.6.6 (r266:84292, Sep 11 2012, 08:34:23) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import pymssql pymssql <module 'pymssql' from 'pymssql.so'>

Going to try to reproduce this on CentOS 5.9 and see what version of libc it has...


Original comment by `msabr...@gmail.com` on 31 Aug 2013 at 5:22
GoogleCodeExporter commented 9 years ago 
OK, I reproduced this problem on a CentOS 5.9 system with glibc 2.3:

[marca@localhost pymssql]$ python setup.py build_ext -i setup.py: platform.system() => 'Linux' setup.py: platform.architecture() => ('64bit', 'ELF') setup.py: platform.linux_distribution() => ('CentOS', '5.9', 'Final') setup.py: platform.libc_ver() => ('glibc', '2.3') setup.py: Using bundled FreeTDS in /home/marca/dev/hg-repos/pymssql/freetds/nix_64 setup.py: include_dirs = ['/home/marca/dev/hg-repos/pymssql/freetds/nix_64/include', '/usr/local/include'] setup.py: library_dirs = ['/home/marca/dev/hg-repos/pymssql/freetds/nix_64/lib', '/usr/local/lib'] running build_ext cythoning _mssql.pyx to _mssql.c building '_mssql' extension creating build creating build/temp.linux-x86_64-2.7 gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/marca/dev/hg-repos/pymssql/freetds/nix_64/include -I/usr/local/include -I/usr/local/include/python2.7 -c _mssql.c -o build/temp.linux-x86_64-2.7/_mssql.o -DMSDBLIB gcc -pthread -shared build/temp.linux-x86_64-2.7/_mssql.o -L/home/marca/dev/hg-repos/pymssql/freetds/nix_64/lib -L/usr/local/lib -lsybdb -lrt -o /home/marca/dev/hg-repos/pymssql/_mssql.so cythoning pymssql.pyx to pymssql.c building 'pymssql' extension gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/marca/dev/hg-repos/pymssql/freetds/nix_64/include -I/usr/local/include -I/usr/local/include/python2.7 -c pymssql.c -o build/temp.linux-x86_64-2.7/pymssql.o -DMSDBLIB gcc -pthread -shared build/temp.linux-x86_64-2.7/pymssql.o -L/home/marca/dev/hg-repos/pymssql/freetds/nix_64/lib -L/usr/local/lib -lsybdb -lrt -o /home/marca/dev/hg-repos/pymssql/pymssql.so [marca@localhost pymssql]$ python Python 2.7.5 (default, Sep 1 2013, 09:47:39) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import pymssql Traceback (most recent call last): File "", line 1, in ImportError: ./pymssql.so: undefined symbol: __vasprintf_chk

Original comment by msabr...@gmail.com on 1 Sep 2013 at 5:41

GoogleCodeExporter commented 9 years ago 
I just added a commit that fixes this issue for me on CentOS 5.9:

https://code.google.com/p/pymssql/source/detail?r=196557e92d5c9db1d26621236a94dc
6481babae1

changeset:   355:196557e92d5c
tag:         tip
user:        Marc Abramowitz <marc@marc-abramowitz.com>
date:        Mon Sep 02 09:31:05 2013 -0700
files:       setup.py
description:
issue 71 ('"undefined symbol: __vasprintf_chk" on some CentOS, RedHat because
of precompiled FreeTDS Linux library')

setup.py: Don't try to use bundled FreeTDS if the system's libc doesn't have a
__vasprintf_chk symbol

If the system's libc doesn't have a __vasprintf_chk symbol, then linking with 
the bundled FreeTDS library is destined to fail, so in this case we don't try 
to link with the bundled FreeTDS. The user is responsible for installing an 
appropriate FreeTDS library.

In some cases, `sudo yum install freetds-devel` might work but on a lot of 
these older distros, it might install a very old version of FreeTDS that won't 
work. In this case, the user is better off downloading the FreeTDS source code 
and building it themselves, making sure to specify the `--enable-msdblib` 
option to `./configure`.

It would be great if folks can verify this change...

Original comment by msabr...@gmail.com on 2 Sep 2013 at 4:36