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
