New version released with a lot of 64-bit, thread, bufferoverrun fixes and more.
Created attachment 193101 [details] ebuild proposal for 2.2.14 Hi, I've manages to prepare an unixODBC ebuild - the gnome stuff is not distributed in the tarball anymore (as i understand this was only GTK1 stuff), so this is gone in the ebuild as well. Qt4 and console odbc config binaries remain and function as far as i tested. - useflag qt4 -> get a working ODBCConfig binary that uses qt4 - no patches are used in the ebuild - sed is used on Makefile.am and exe/Makefile.am to unbundle pkg's libltdl and use the system installed ltdl latest soprano-scm from kde-experimental overlay needs this (and compiles wonderfully once unixODBC is upgraded).. have fun, Christian (cmuelle8)
> - sed is used on Makefile.am and exe/Makefile.am to unbundle pkg's libltdl and > use the system installed ltdl This is Just Plain Wrong. This has to stop. There are tweaks to the bundled libltdl that need to be referenced. So quite likely, even this is wrong: https://bugzilla.redhat.com/show_bug.cgi?id=237477 There are specific bits to the bundled library that are REQUIRED for perl DBD::ODBC. Not using that library is a problem. See more info http://bugs.gentoo.org/show_bug.cgi?id=230243 The bug is also -- to a casual observer -- mis-assigned. This has nothing whatsoever to do with PHP. Can we please get this assigned to some other group, or an explanation as to why the PHP folks are going to fix a bug with a fix needed specifically for perl DBD::ODBC users?
OK, thanks for some input on this - unfortunately I did not succeed in getting the bundled libltdl to compile. Sure there's lots of stuff that relies on DBD::ODBC, but I think it's better having an option for people who don't need this, than *nothing*. If you have an updated ebuild that works with the bundled libltdl, feel free to upload to this bug. The bug misassignment should be changed by bug-wranglers, right? Thanks, cmuelle8
btw, the unbundling has happened in 2.12 too. do you say, this is the cause for bug #230243 as well and the reason for the backup to 2.11? but then since 2.11 lots of things for amd64 were fixed..
It's NOT mis-assigned. # cat /usr/portage/dev-db/unixODBC/metadata.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> <pkgmetadata> <herd>php</herd> </pkgmetadata> This dates back to when PHP was the only thing in the tree that used unixODBC. If there's another developer that wants it, I'm sure PHP would be happy to be rid of it. What is unixODBC doing to ltdl that isn't in the system ltdl? The problem with their shipped ltdl used to be that it wasn't even remotely 64-bit safe.
pinpoint: Although we want to use the latest libltdl, there is one patch that must be made to avoid problems in Perl::ODBC: don't use RTLD_GLOBAL in the call to dlopen(). diff -Naur unixODBC-2.2.11.save/libltdl/ltdl.c unixODBC-2.2.11/libltdl/ltdl.c --- unixODBC-2.2.11.save/libltdl/ltdl.c 2005-09-29 16:18:17.000000000 -0400 +++ unixODBC-2.2.11/libltdl/ltdl.c 2005-09-29 16:45:11.000000000 -0400 @@ -1107,7 +1107,12 @@ lt_user_data loader_data; const char *filename; { - lt_module module = dlopen (filename, LT_GLOBAL | LT_LAZY_OR_NOW); +/* + * this need takeing out, otherwise things like perl break + * lt_module module = dlopen (filename, LT_GLOBAL | LT_LAZY_OR_NOW); + */ + + lt_module module = dlopen (filename, LT_LAZY_OR_NOW ); if (!module) { There is a link to this in #230243 as posted above by michael higgins.. Greetings
(In reply to comment #6) > pinpoint: > > Although we want to use the latest libltdl, there is one patch that must > be made to avoid problems in Perl::ODBC: don't use RTLD_GLOBAL in the > call to dlopen(). > I don't believe this is possible in the version on the system. Robin Johnson: Thanks for the explanation of the apparent mis-assignment. > What is unixODBC doing to ltdl that isn't in the system ltdl? Wow. If I knew... anyway, in the link I posted: <quote> Comment #1 From Tom Lane 2008-02-11 19:11:38 EDT ------- Is this a big problem? The changelog notes Use private libltdl so we can omit RTLD_GLOBAL from dlopen flags (bz #161399) so I'm worried about suffering a regression if we try to use libltdl.so. </quote> And in the other link I posted, this to another Gentoo bug report: "And finally, I've done all I can. With some way to disable LT_GROUP in the build, this hack isn't needed. Problem is, the gentoo ebuilds link to system libs, where the file that defines this doesn't have the same code as the one their code ships with." I'll note here: "...in their bundled ltdl.c file in the latest: /* * This needed fixing for any number of reasons, including Perl DBD::ODBC */ So, the problem is clear. Either unixODBC gets built with the libltdl it ships with (last working versions were < 2.2.12, when Gentoo ebuild "unbundled" it), or DBD::ODBC won't work, full stop. I did some reading and as far as I can tell, this (bundling a possibly altered older version of libltdl) is not that uncommon, even though from several perspectives is certainly less than an ideal solution. Anyway, you know what to do. The problem has been reported to Gentoo for exactly a year, today. Happy birthday, bug! http://bugs.gentoo.org/show_bug.cgi?id=230243 Opened: 2008-06-30 19:43 0000 I'll send along the patch that's still needed to that library (at least until another release, I suppose). Also, I (re-)created the unixODBC-2.2.14-libltdlfixes.patch just to see if it helped. (It didn't.)
Has anyone tried yet to use the patch from comment #6 with the system ltdl? Is this the only modification unixODBC does to libltdl or are there other 'tweaks'? If both questions have a positive answer, wouldn't it be possible to 1) strip the supplied ltdl 2) embed the system ltdl 3) then use the patch (#6) on ltdl/ltdl.c ("customize system ltdl") 4) do src_compile Thanks for any input.. cmuelle8
(In reply to comment #7) > (In reply to comment #6) > > pinpoint: > > > > Although we want to use the latest libltdl, there is one patch that must > > be made to avoid problems in Perl::ODBC: don't use RTLD_GLOBAL in the > > call to dlopen(). > > > > I don't believe this is possible in the version on the system. To clarify my suggestion and to see if I get you right: - using the patch on the system ltdl that packages dynamically link to is a no brainer, since any package using system ltdl would be affected by it. is this what you mean by saying the above "I don't believe [..] on the system."? - my suggestion is to not link to the system ltdl from unixODBC, but rather build a private ltdl (embedded) which is a src_copied and patched system-version at ebuild runtime, roughly: rm -rf ltdl libtoolize --ltdl=ltdl patch < unixODBC.custom.ltdl.patch The problem with this is, that if the patch is large, it might break often with each new version of the system's libtool package.. Greetings, cmuelle8
Perhaps somebody could write a summary of the problem: what's happening, why (according to unixODBC devs) it happens, how they've "solved" it, etc. and post it as a question on libtool list, just so the other part of the equation is seen. Perhaps they will know a better solution (or at least, maybe some kind of compromise can be reached). After all, in libtool 2, many things have changed, so it's possible, it's fixed there. Unless it's a problem with how perl handles things, then I don't see this getting fixed in any near future.
OK, as nobody really cared, I asked that question myself. It's at http://thread.gmane.org/gmane.comp.gnu.libtool.general/10285/ The short of it is that to solve the problem of RTLD_GLOBAL without using bundled (patched) libtool, unixODBC should be ported to libtool 2, as that version has a new call, that handles this problem.
I guess the qt dependencys are not ok. it shouldn't depend on the meta-package. I got it installed with qt-core and qt-assistant in the dependencies. But i don't know what is really needed. I couldn'f find any docu about the particular qt dependencies.
Created attachment 207355 [details] patch for the qu dependencies - just a suggestion of mine
(In reply to comment #5) > It's NOT mis-assigned. > # cat /usr/portage/dev-db/unixODBC/metadata.xml > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> > <pkgmetadata> > <herd>php</herd> > </pkgmetadata> > > This dates back to when PHP was the only thing in the tree that used unixODBC. > If there's another developer that wants it, I'm sure PHP would be happy to be > rid of it. > > What is unixODBC doing to ltdl that isn't in the system ltdl? The problem with > their shipped ltdl used to be that it wasn't even remotely 64-bit safe. > per above, I've bumped to 2.2.14 and added myself to metadata.xml, leaving php as backup
