Re: FreeTDS, unixODBC and DBD::ODBC
Martin J. Evans wrote: col wrote: [8] So, I thought you folks should hear about it all again. HTH... else, sorry for the noise. [8] I spoke to Nick and he reminded me why this can happen. Thanks *very* much for that. See http://www.easysoft.com/support/kb/kb00664.html http://groups.google.com/group/perl.dbi.users/browse_thread/thread/995131d999ca388/370b10f358e31729?hl=enlnk=gstq=Segmentation+fault+on+RHEL4#370b10f358e31729 And thanks for the links. I had already run across this and attempted to rebuild unixODBC --enable-rtldgroup=no to no apparent effect. I'll try again. It is probably down to using RTLD_GLOBAL on the dlopen call which causes symbols to be resolved top down instead of from where the symbol was found to be undefined downwards. You can stick with what you are doing or rebuild unixODBC but it seems a permanent change to unixODBC is not possible because the problem is in libtool so every time unixODBC is reconfigured libtool replaces the change to remove RTLD_GROUP. ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --host=i686-pc-linux-gnu --prefix=/usr --sysconfdir=/etc/unixODBC --libdir=/usr/lib --enable-static --enable-rtldgroup=no --enable-fdb --build=i686-pc-linux-gnu ... checking Have we enabled using RTLD_GROUP ... no [...] No change: perl dbix_odbctest.pl Segmentation fault We had a similar problem a while ago with RHEL3 which was solved by installing the latest unixODBC (2.2.14) -- but without disabling RTLD_GROUP. (Actually, the problem was slightly different in that the DBI-connect failed rather than segfaulting, but maybe that was due to version differences in other software). We found Martin's reply to http://www.issociate.de/board/goto/565693/DBD::ODBC,_unixODBC,_FreeTDS,_MS-SQL,_lazy_DL,_dbd_db_login/SQLSetConnectOption_err=-2.html (the first reply in the same page) helpful, since unixODBC 2.2.8 is the default version in RHEL3 and a recent Fedora containing 2.2.11 worked correctly. best regards, John Escott.
DBD::Oracle 1.23 and instant client 10.2.0.4
Somewhat related to Jeff's mail. I recently built DBD::Oracle 1.23 against Oracle instant client on a 32 bit linux box and got the following warning: Reading /usr/share/oracle/10.2.0.4/client/demo.mk WARNING: Oracle /usr/share/oracle/10.2.0.4/client/demo.mk doesn't define a 'build' rule. WARNING: I will now try to guess how to build and link DBD::Oracle for you. This kind of guess work is very error prone and Oracle-version sensitive. It is possible that it won't be supported in future versions of DBD::Oracle. *PLEASE* notify dbi-users about exactly _why_ you had to build it this way. Found header files in /usr/include/oracle/10.2.0.4/client. The rules defined by demo.mk are: all buildoci buildocci plus a bunch of others which don't look relevant. hp -- _ | Peter J. Holzer| Auf jedem Computer sollte der Satz Ludwigs II |_|_) | Sysadmin WSR | eingeprägt stehen: Ein ewig Rätsel will ich | | | h...@wsr.ac.at | bleiben, mir und andern. __/ | http://www.hjp.at/ |-- Wolfram Heinrich in desd signature.asc Description: Digital signature
Re: FreeTDS, unixODBC and DBD::ODBC
On Fri, 26 Jun 2009 08:44:28 +0200 John Escott j...@scanlaser.nl wrote: (the first reply in the same page) helpful, since unixODBC 2.2.8 is the default version in RHEL3 and a recent Fedora containing 2.2.11 worked correctly. John -- Thanks for your reply. Actually, the problem is consistent and appears only *after* unixODBC version 2.2.11 -- that is the very last version that works. All subsequent releases exhibit this segmentation fault failure. So far nothing suggested to apply in the compile stage is fixing it. The ld.so.preload hack is not a fix at all IMO, but I'm neither C programmer, nor distro packager. I just dislike ugly hacks and as a sysadmin, *really* wouldn't mind never thinking of this again. Unfortunately, I'm just not in a position to figure it out. I've done my bit to complain and report on this since version 2.2.12 broke my system, all to no effect. Someone else has to want to fix this. It was suggested that Debian actually has this working out of the box, but I'm guessing they have a ld.so.preload hack for it to work, or maybe they package an older version that still works, like 2.2.11 (I guess that's what you just wrote). I suppose I could just go back to that version too, but 2.2.12 was out a long time ago and 2.2.14 is the latest. I mean, aren't we supposed to help fix bugs for new releases? Anyway, the problem is known, the fix should be made available, but first, there has to be an acknowledgement of the problem by unixODBC folks, something I've yet to see... it's almost as if there was some *other way* to do this... *not* using FreeTDS. Otherwise, this would be a major problem with the package, and something necessitating a fix, no? Anyway, I'm done ranting. Time for me to just accept defeat in this area and move on. Does anyone know, is there an open source replacement for unixODBC? Why do we need this thing anyway for DBD::ODBC? Shouldn't it work without it? Cheers, -- |\ /|| | ~ ~ | \/ ||---| `|` ? ||ichael | |iggins\^ / michael.higgins[at]evolone[dot]org
Re: FreeTDS, unixODBC and DBD::ODBC
col wrote: On Fri, 26 Jun 2009 08:44:28 +0200 John Escott j...@scanlaser.nl wrote: (the first reply in the same page) helpful, since unixODBC 2.2.8 is the default version in RHEL3 and a recent Fedora containing 2.2.11 worked correctly. John -- Thanks for your reply. Actually, the problem is consistent and appears only *after* unixODBC version 2.2.11 -- that is the very last version that works. All subsequent releases exhibit this segmentation fault failure. So far nothing suggested to apply in the compile stage is fixing it. Can I just verify whether you have configured unixODBC then removed the LT_GLOBAL from the dlopen call then configured again and ensured LT_GLOBAL is in the dlopen call. One of those should fix it - I believe it is the removing of LT_GLOBAL. One of the FAQs suggests LT_GROUP needs removing but I thought it was LT_GROUP which needed to be in place. The problem this addresses is dynamic resolution of symbols. The perl runs and DBI loads ODBC.so which is linked to libodbc.so. When you call DBI-connect, unixODBC will load the driver and locate the symbols but once this has happened the next call to a SQLxxx ODBC fn ends up directly in the ODBC driver instead of in unixODBC. As your application had a connection handle given to it via unixODBC, the first ODBC call after connect from the app/DBD::ODBC ends up in the SQLxxx fn in the driver with a unixODBC handle instead of a driver handle then when the driver attempts to use that pointer it can easily segfault because it points at a structure it never created. If this was your problem then you could identify it precisely by enabling unixODBC logging and doing a simple connect (which segfaults) - is there anything in the log? e.g., add the following to your odbcinst.ini file: [ODBC] Trace = yes TraceFile = /tmp/unixodbc.log The ld.so.preload hack is not a fix at all IMO, but I'm neither C programmer, nor distro packager. I just dislike ugly hacks and as a sysadmin, *really* wouldn't mind never thinking of this again. From the above explanation you can maybe see how this fixes it. At this stage you only have a few choices a) throw it all away and stop using it b) use the ugly hack c) try more to get to the bottom of it. My guess is you won't be doing (a) and will almost certainly do (b) until someone sorts it out for you - but that will probably require more of (c). Unfortunately, I'm just not in a position to figure it out. I've done my bit to complain and report on this since version 2.2.12 broke my system, all to no effect. Someone else has to want to fix this. The first problem here is we are not sure what problem you have - we can only guess based on the ugly hack. The second problem is other than John (who is working now) you are the only person with this problem - I don't have it on Linux Ubuntu using either unixODBC and freeTDS supplied by Ubuntu or when I build everything myself. Neither does anyone else I know (and I know a lot (1000s) of people using unixODBC). If we had access to the machine which is failing we might be able to find out what is wrong but in the mean time we are still not 100% sure what the problem is and we are not sure what exactly you have tried. since version 2.2.12 broke my system, all to no effect. Someone else has to want to fix this. I don't want to get into an argument with you about this but I think all to no effect is a little unfair. You got responses to your request for help almost immediately, you say you have tried some and now just want to give up and say it is someone else's problem. It is not my problem or anyone elses - all the software you are using is free and there is no obligation on anyone I know to help you but some are trying. You also seem to have a workaround but you don't like it. It was suggested that Debian actually has this working out of the box, but I'm guessing they have a ld.so.preload hack for it to work, or maybe they package an older version that still works, like 2.2.11 (I guess that's what you just wrote). It works out of the box for me on ubuntu as well and also with the latest of unixODBC and freeTDS built by hand and with preload untouched. I suppose I could just go back to that version too, but 2.2.12 was out a long time ago and 2.2.14 is the latest. I mean, aren't we supposed to help fix bugs for new releases? I am not sure what you mean by that. Anyway, the problem is known, the fix should be made available, but first, there has to be an acknowledgement of the problem by unixODBC folks, something I've yet to see... it's almost as if there was some *other way* to do this... *not* using FreeTDS. Otherwise, this would be a major problem with the package, and something necessitating a fix, no? A fix might be made available once someone has identified the problem - that has not happened yet. I personally dislike your comments made at people who wrote and maintain a large piece of software for
DBD::ODBC make test fails - unixODBC/Easysoft/SQL Server 2008
Getting closer :) I'm trying to connect to a SQL Server 2008 instance from a CentOS5 box: unixODBC: 2.2.14 FreeTDS:0.82 Easysoft: odbc-sqlserver-1.1.26-linux-x86 (this morning, thank you again Martin and Wez...) osql/isql work fine with both the FreeTDS and the Easysoft drivers. Connecting to a SQL Server 2008 instance running on a Server 2008 box. DBB::ODBC make test fails as follows: [r...@server1 DBD-ODBC-1.22-D2_Zne]# make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/01base.t .. ok t/02simple.t 3/65 # # Perl 5.8.8 # osname=linux, osvers=2.6.18-53.el5, archname=i386-linux-thread-multi # Using DBI 1.609 # Using DBD::ODBC 1.22 # Using DBMS_NAME 'Microsoft SQL Server' # Using DBMS_VER '10.00.1600' # Using DRIVER_NAME 'libessqlsrv.so' # Using DRIVER_VER '01.01.0026' # odbc_has_unicode 0 t/02simple.t 35/65 # Failed test 'data sources test' # at t/02simple.t line 259. # '0' # # '0' # Looks like you failed 1 test of 65. t/02simple.t Dubious, test returned 1 (wstat 256, 0x100) Failed 1/65 subtests t/03dbatt.t . 3/29 # # N.B. Some drivers (postgres/cache) may return ODBC 2.0 column names for the SQLTables result-set e.g. TABLE_QUALIFIER instead of TABLE_CAT t/03dbatt.t . ok t/05meth.t .. ok t/07bind.t .. ok t/08bind2.t . ok t/09multi.t . ok t/10handler.t ... ok t/12blob.t .. ok t/20SqlServer.t . ok t/30Oracle.t ok t/40UnicodeRoundTrip.t .. ok t/41Unicode.t ... ok t/pod-coverage.t ok t/pod.t . ok t/rt_38977.t ok t/rt_39841.t ok t/rt_39897.t ok t/rt_43384.t ok t/rt_46597.t ok t/rt_null_nvarchar.t ok Test Summary Report --- t/02simple.t (Wstat: 256 Tests: 65 Failed: 1) Failed test: 56 Non-zero exit status: 1 Files=21, Tests=445, 33 wallclock secs ( 0.02 usr 0.26 sys + 0.27 cusr 2.17 csys = 2.72 CPU) Result: FAIL Failed 1/21 test programs. 1/445 subtests failed. make: *** [test_dynamic] Error 255 As always, thanks! Best regards, Scott...
Re: FreeTDS, unixODBC and DBD::ODBC
On Fri, 26 Jun 2009 17:47:13 +0100 Martin Evans martin.ev...@easysoft.com wrote: col wrote: So far nothing suggested to apply in the compile stage is fixing it. Can I just verify whether you have configured unixODBC then removed the LT_GLOBAL from the dlopen call then configured again and ensured LT_GLOBAL is in the dlopen call. One of those should fix it - I believe it is the removing of LT_GLOBAL. One of the FAQs suggests LT_GROUP needs removing but I thought it was LT_GROUP which needed to be in place. Okay, I'll try this again. I did remove a piece of some .c file... diff ./libltdl/ltdl.c ../ltdl.c.new 1135c1135 lt_module module = dlopen (filename, LT_GROUP | LT_LAZY_OR_NOW | LT_MEMBER ); --- lt_module module = dlopen (filename, LT_LAZY_OR_NOW | LT_MEMBER ); I assume this is what you meant. So, I: ./configure --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --localstatedir=/var/lib --host=i686-pc-linux-gnu --prefix=/usr --sysconfdir=/etc/unixODBC --libdir=/usr/lib --enable-static --enable-rtldgroup=no --enable-fdb --disable-gui --build=i686-pc-linux-gnu Then: patch -p1 ../unix_odbc_lt-group.patch patching file libltdl/ltdl.c make make install (let me note that I haven't issued this command in a few years, so I'm going to assume this wound up in the right places, having cribbed the ./configure from the Gentoo ebuilds.) emerge DBD-ODBC (does this matter? IDK. Possibly.) The problem this addresses is dynamic resolution of symbols. Eh? '-) Unfortunately, I am wholly lost at this point. My purpose is to abstract it away with an ORM and get data flowing to eyes. ;-) I truly do appreciate your explaining, though. If this was your problem then you could identify it precisely by enabling unixODBC logging and doing a simple connect (which segfaults) - is there anything in the log? e.g., add the following to your odbcinst.ini file: [ODBC] Trace = yes TraceFile = /tmp/unixodbc.log Is all there, should write to my user Desktop... Never, ever seen an unixODBC trace file...ODBC_Trace??? Isn't that a configure option to build a library for that, or something? Maybe should be enabled? [8] If we had access to the machine which is failing we might be able to find out what is wrong but in the mean time we are still not 100% sure what the problem is and we are not sure what exactly you have tried. Well, short of ditching the package manager and distro, I tried all the whining I could muster, I suppose. Okay, building as you described does seem to work. Yeah! THANK YOU! (I knew you could do it.) Now, the problem -- for ME -- is, I'll be stuck having to make a new ebuild or pursue a bug for same (and I do really lack the relevant proficiencies), and what I'd like is to be out of it entirely and still see it fixed. since version 2.2.12 broke my system, all to no effect. Someone else has to want to fix this. I don't want to get into an argument with you about this but I think all to no effect is a little unfair. Whoa! I meant, I'm still getting a generic segfault. You've been very responsive every time, I know. You got responses to your request for help almost immediately, you say you have tried some and now just want to give up and say it is someone else's problem. No, just that as I can't fix it, someone else has to -- or it won't be fixed! I suppose that's really not a problem, true. It is not my problem or anyone elses Agreed. '-) [8] It works out of the box for me on ubuntu as well and also with the latest of unixODBC and freeTDS built by hand and with preload untouched. Okay, maybe I can find out what they do... I looked at the Gentoo ebuild and they try to link to the system ltld, or whatever it is, nuking the whole folder from the unixODBC tarball. So, all this is irrelevant to the build system they have. IDK why, can't speculate, but NOW, at least I can say there is *something* that could be done better. I hope it's to be a Gentoo dev's problem, now I have enough info to say something useful (perhaps) about it. Some days, I'm really thinking Gentoo is not good for my health, overall. I suppose I could just go back to that version too, but 2.2.12 was out a long time ago and 2.2.14 is the latest. I mean, aren't we supposed to help fix bugs for new releases? I am not sure what you mean by that. Me neither, at this point. I guess I'm trying to find a way to get this problem resolved on the distro I use, so I can put on my webmonkey/perlscripter's hat and have some fun, without worrying that everything will break next week or month when I update all my systems. Anyway, the problem is known, the fix should be made available, but first, there has to be an acknowledgement of the problem by unixODBC folks, something I've yet to see... it's almost as if there was some *other way* to do this... *not* using FreeTDS. Otherwise, this
Re: FreeTDS, unixODBC and DBD::ODBC
On Thu, 25 Jun 2009 21:40:07 +0100 Martin J. Evans martin.ev...@easysoft.com wrote: I'm not sure the --enable-rtldgroup=no works now because of libtool changes. I think you may need to configure unixODBC then edit the file and delete the LT_GROUP. This appears to be an issue with libtool which was worked around in the past but the workaround does not work now because libtool has changed and regenerates the code in a way --enable-rtldgroup cannot work. Martin Martin -- In: unixODBC-2.2.14/libltdl/ltdl.c line 1063 of 4543 : /* * This needed fixing for any number of reasons, including Perl DBD::ODBC */ ... so, that comment line would seem to indicate that: # Remove bundled libltdl copy rm -rf libltdl ... from the unixODBC ebuild script I linked you to, is pretty much going to cause usage failure for DBD::ODBC, since it deletes the file which needed fixing for... DBD::ODBC. So, like, is that about it? '-) And, so even though that file was fixed for DBD::ODBC, it probably still needs fixing a bit more... as I just finished patching my copy of it at your suggestion? Now, what I don't understand is, why this package *doesn't* use whatever... system libltdl. Again, all I can say is I know nothing about the actual code that makes all this stuff work, or compiling, or really, much of anything hard about computing. I just want Gentoo perl users (both of us) to be able to have an ebuild that works to make something DBD-ODBC can use. Cheers, -- |\ /|| | ~ ~ | \/ ||---| `|` ? ||ichael | |iggins\^ / michael.higgins[at]evolone[dot]org
