Arch Linux

dpriedel

Member

Registered: 2010-12-16

Posts: 19

myodbc

I've just installed the x86_64 package for myodbc,version 5.1.9-2

When I try to do some SQL using this module (via pyodbc and python) I get this error:

/usr/bin/python2: symbol lookup error: /usr/lib/libmyodbc5.so: undefined symbol: strfill

Looking at the code, I believe strfill is supposed to come from some mysql library but it isn't there. Hence the symbol error.

NOTE:  I do have a working mysql installation.

I have gotten around this issue in the past by modifying the utility.c program in the myodbc source to replace the call to strfill with a call to memset which seems to do the trick but this is less than ideal since I need to apply this patch every time myodbc is upgraded.

suggestions ??

thanks

dave

fsckd

Forum Fellow

Registered: 2009-06-15

Posts: 4,173

Re: myodbc

After a cursory check I think strfill is provided by libmysqlclient which is a dependency of myodbc.

---

aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies

dpriedel

Member

Registered: 2010-12-16

Posts: 19

Re: myodbc

doing a readelf -s /usr/lib/libmysqlclient.so | grep -i strfill yields no matches so I think it's not in that library.

dpriedel

Member

Registered: 2010-12-16

Posts: 19

Re: myodbc

Is anyone having problems with myodbc 5.11?

I installed the update on an up-to-date x86_64 Arch system and I get undefined symbol errors.  Looking into things, I find that the make files for the library do not build the my_stmt.c and my_prepared_stmt.c modules.  After taking care of that, I'm back to the missing strfill method (which I will replace with a call to memset).

Dave

dpriedel

Member

Registered: 2010-12-16

Posts: 19

Re: myodbc

Hi

I'm still looking into this problem with the missing strfill routine in libmysqlclient.

I downloaded the source code and built the library myself and what I seem to find is that strfill is in the static version of libmysqlclient, but not the dynamic version.  I demonstrate this by:

grep strfil libmysqlclient.a
Binary file libmysqlclient.a matches

and
readelf -s libmysqlclient.so | grep strfill

which gets no hits.

Looking through the makefiles, it looks like it should be in both.

I'm really puzzled by this.  The end result is that myodbc won't run because it can't find the strfill routine....

Ideas??

thanks

dave

dpriedel

Member

Registered: 2010-12-16

Posts: 19

Re: myodbc

Hi

I've continued looking into this and here is what I've found.

NOTE: this is for the x86_64 build.

1. The Makefiles generated from configure do not include all the pieces necessary to actually build my_prepared_stmt.c and my_stmt.c.

2, libmysqlclient.so does not include the strfill routine.  (strfill IS included in libmysqlclient.a but that doesn't help us.) 

3. The myodbc.so file downloaded from the dev.mysql.com site includes strfill.

So....what I've done is:

1. download the complete source to mysql server from dev.mysql.com

2. copy strfill.c to my pyodbc/util directory.

3. modify the CMakeLists.txt in the util directory to include strfill.c

4 run cmake to rebuild the Makefiles.

5 run make and then rebuild the package file.

I now have a working myodbc.so module.

NOTE: some steps have been left out because this is a hack and I am guessing on some cmake and makepkg things.

I hope this helps someone or maybe someone has a  better way to do this.

Dave

dpriedel

Member

Registered: 2010-12-16

Posts: 19

Re: myodbc

Hi again

Well, myodbc-5.11-3 is available which does fix a couple of the problems with the earlier versions BUT...it is still missing strfill !

ldd libmyodbc5.so
    linux-vdso.so.1 =>  (0x00007fff82fff000)
    libodbc.so.2 => /usr/lib/libodbc.so.2 (0x00007f65c575e000)
    libmysqlclient.so.18 => /usr/lib/libmysqlclient.so.18 (0x00007f65c5284000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007f65c5067000)
    libm.so.6 => /lib/libm.so.6 (0x00007f65c4d72000)
    libodbcinst.so.2 => /usr/lib/libodbcinst.so.2 (0x00007f65c4b61000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007f65c495c000)
    libc.so.6 => /lib/libc.so.6 (0x00007f65c45bb000)
    libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f65c43b1000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f65c419a000)
    libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f65c3f30000)
    libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f65c3b27000)
    /lib/ld-linux-x86-64.so.2 (0x00007f65c5c38000)

shows no unresolved library pointers.

readelf -s libmyodbc5.so | grep strfill
62: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND strfill

shows strfill is undefined in the module so myodbc is not usable.

I think the problem must be upstream -- the source and makefiles from Oracle don't yield a working library.

In the interim, I think there are 2 work-arounds.

1. add the strfill.c source to the project
or
2. link against the static libmysqlclient.a which does include strfill unlike libmysqlclient.so which does NOT. (Why this is so, I don't know -- it looks like it should be included).

Thanks

Dave