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 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. Well, if the build I have now works, but not the one as distributed by Gentoo, can you explain to the maintainers at Gentoo what the problem is? Even now, I don't think I have a prayer of getting this fixed. > I personally dislike your comments made > at people who wrote and maintain a large piece of software for free. > I was going to say more but I've bitten my tongue instead. You are surely a better man than I. Really. I'm not nice by nature or design. But, in my own defence I will, and do, try to be helpful in return, when I can. > > > Anyway, I'm done ranting. [I guess I wasn't.] > Try building freeTDS with > DBD::ODBC without one or (use threads or unicode) and you'll soon see > why. Heh. There you go. I have no idea what this could possibly mean. Again, I'm most grateful for your attention to this matter. Cheers, -- |\ /| | | ~ ~ | \/ | |---| `|` ? | |ichael | |iggins \^ / michael.higgins[at]evolone[dot]org
