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.
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
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
Re: FreeTDS, unixODBC and DBD::ODBC
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
Re: FreeTDS, unixODBC and DBD::ODBC
Martin J. Evans wrote: 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 I spoke to Nick and he reminded me why this can happen. 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 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. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: FreeTDS, unixODBC and DBD::ODBC
On Thu, 25 Jun 2009 10:10:03 +0100 Martin Evans martin.ev...@easysoft.com wrote: 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 LD_BIND_NOW=1 perl dbix_odbctest.pl trex connected Honestly, I'd already explored this option, or so I thought. This is the script used to make the unixODBC build: http://bugs.gentoo.org/attachment.cgi?id=193101action=view ... which is possibly deficient in some way. IDK. I just added the rtld_group configure option, which does seem to be honoured when passed to ./configure. I'm lost, pretty much, at this point. I'll bring my findings to the unixODBC folks as well. Thanks for all your help with this! Cheers, -- |\ /|| | ~ ~ | \/ ||---| `|` ? ||ichael | |iggins\^ / michael.higgins[at]evolone[dot]org
Re: FreeTDS, unixODBC and DBD::ODBC
col wrote: On Thu, 25 Jun 2009 10:10:03 +0100 Martin Evans martin.ev...@easysoft.com wrote: 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 LD_BIND_NOW=1 perl dbix_odbctest.pl trex connected Honestly, I'd already explored this option, or so I thought. This is the script used to make the unixODBC build: http://bugs.gentoo.org/attachment.cgi?id=193101action=view ... which is possibly deficient in some way. IDK. I just added the rtld_group configure option, which does seem to be honoured when passed to ./configure. I'm lost, pretty much, at this point. I'll bring my findings to the unixODBC folks as well. Thanks for all your help with this! Cheers, 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
