col wrote: > First, let me assure you all I know nothing about the actual code that makes > all this stuff work, or compiling, or really, much of anything "hard" about > computing. So, this could be pure malarkey. Anyway... > > There appears to be a linking problem when using libtdsodbc from DBD::ODBC > which causes a segfault on a connect attempt. This is, I think, missed during > routine testing because of PERL_DL_NONLAZY being set from Test::More. > > However, using DBIx-Class, for example, the connect call is somehow deferred > until the last possible minute, so this hack / workaround, of setting > PERL_DL_NONLAZY in a BEGIN block no longer works. Well, I can say surely it > doesn't work for me, really not exactly why that is. > > Setting LD_BIND_NOW *does* work in this situation, however. But it has to be > set outside the perl script. > > This lead me to adding /usr/lib/libtdsodbc.so to /etc/ld.so.preload. > Magically, all the segfault problems go away. But since this is only needed > for DBD::ODBC, I think it's better to fix the problem there, or with > unixODBC, which should successfully load libtdsodbc before it's needed, since > it's linked to it. If that's, indeed, the problem... > > I'm hoping that someone close to the code is interested enough to (help) > pursue this with the respective maintainers of these ODBC driver/manager > packages, or make some suggestions to the DBD::ODBC build script, to figure > out why this is happening and maybe solve it. ;-) > > For myself, I use Gentoo, so always assumed maybe some fault there, but this > just happened with a RedHat user as well, who says, "This should probably be > noted on the documentation pages since I assume anyone running a similar > linux such as redhat 3 will experience the same issue." > > So, I thought you folks should hear about it all again. HTH... else, sorry > for the noise. > > Cheers, >
(reposted as I forgot dbi-users originally) I'm sorry to hear you've had so much trouble with this and note you've posted on the freeTDS list in the past week. Probably the best place for this is on the unixODBC list. I think your problem is down to deferred linking but if it was as simple as that I would expect to have seen this before on the unixodbc or freetds lists and I haven't until now. "or with unixODBC, which should successfully load libtdsodbc before it's needed, since it's linked to it" What you need to understand is that unixODBC is an ODBC Driver Manager used to isolate the application from the ODBC Driver. The driver manager does a whole lot more than simply load the driver - see any online docs. unixODBC cannot load your driver until you call connect because until you call connect it has no idea which driver you want to use - in fact it is the same using DBI - until you call DBI's connect method it does not know which DBD you are going to use. As a result, it is impossible for DBI to load the DBD or for unixODBC to load freetds and they are NOT directly linked at all. The only dependent linking is between DBD::ODBC's ODBC.so and libodbc.so (the driver manager) which you can see if you run ldd on ODBC.so. Similarly, if you run ldd on libodbc.so you will see it is not (and cannot be) linked to any particular driver. I suspect this may be down to how unixODBC was built (where did you get yours from) as there are a plethora of arguments to dlopen which may impact this. It could also be something to do with shared objects (e.g., freetds) attempting to register unload callbacks (or whatever they are called these days). I think you'd be better pursuing this on the unixodbc/freetds lists with as much info as possible as it is quite possible Nick Gorham (of unixODBC) will know the answer or be able to find one. freetds version, unixodbc version, linux version, ldd and ld.so version, how unixodbc and freetds were built, whether you are using selinux etc. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
