Bugzilla – Bug 142224
Shipped php4-unixODBC is broken
Last modified: 2006-04-15 21:54:07 UTC
php4-unixODBC bundled with SuSE final 10 is broken. Invoking ODBC functions from within a PHP script produces the following error: php: symbol lookup error: /usr/lib/php/extensions/unixODBC.so: undefined symbol: SQLAllocEnv
Please attach the script you're trying to parse here. Did you do any updates or is this a plain out-of-the-box installation of your Apache-Environment? Looks like a library incompatibility to me.
Created attachment 62729 [details] This PHP script produces the error, even when run from the command line without a web server in place I am attaching a script that produces the error, no matter which ODBC driver is used. The same script works fine on SuSE 9.1. I see the problem with SuSE 10 out of the box (completely unpatched) and also SuSE 10 completely patched using YOU. Also googling shows a number of other people experiencing the same issue on SuSE boxes.
Petr: Is this a known issue?
I don't know anything about it, but I will investigate it.
seems extension is compiled againts the wrong library version or something. I will also look into this later
Any developments? This is forcing us to keep SuSE 9.1 boxes and prevents us from upgrading to SuSE 10.
(In reply to comment #6) > Any developments? AFAIK, no, the only bad news is this extension seems to be broken in 10.1 too. :-( This is forcing us to keep SuSE 9.1 boxes and prevents us > from upgrading to SuSE 10. > if somebody of the reporters can give me access to the offended systems ( unprivleged of course ) and if** I have time**, **maybe** I can debug this problem, but no promises at all. if the problem is compatibility with the oracle thing, the only solution is RTFB :-P and that's not an option for me. and since oracle is taking 3 years to fix bugs on their products..... this doesn't look promising...
The problem is not related to Oracle at all, I can reproduce it with about any unixODBC connection - I have "breaking" examples of Oracle as well as Sybase. I can look into getting you access to a system that exhibits the issue, though that may take some time on my end - a terminal via SSH will be enough?
yes, and install gdb , valgrind , apache2-debuginfo ... and use PHP5...PLEASE (and install php-debuginfo too ) ssh will be enough, drop me a private email with details again , no promises, Im quite busy at this time.
I am investigating it and I found some info about this problem on SL http://susewiki.org/index.php?title=PHP4_ODBC I don't know but on one machine there isn't problem with unresolved symbol, but php segfauls with this test ;), I need more time to solve all these problems. Cristian thnx for your invetsigation ;)
ok for unresolved symbol you need php4-snmp package ;( (the requirepments weren't solved for php4 it should be check automatically by script (I will do it later).
php-snmp (?????):S not in the documentation .. http://php.net/odbc :( BTW. Petr : this is broken since 9.2 ... I hope this can be fixed for 10.1 ;-) To all the affected people : COnsidere an upgrade to PHP5, next SUSE release do not ship PHP4 anymore.
Created attachment 72472 [details] Proposed replacement for php-4.4.0-autoconf1.diff to make php4-unixODBC usable
Sorry, not yet familiar with this bugzilla. This message should have been above the new attachment message. I've also been hit by this issue, and decided to investigate the src.rpm (php4-4.4.0-6.src.rpm). I traced the issue down to an apparently broken patch to the pristine sources (autoconf1.diff). So I've changed this patch in a way that unixODBC.so gets correctly linked against libodbc.so, which was prevented by the mistake in the original patch. The src.rpm compiles nicely for me, ODBC works witout the need for php4-snmp. I've attached my new patch.
thnx for patch
Soenke Dibbern, thank you for the patch. I had already given up on the issue and ported the application to PHP5, which does not exhibit the issue. Thanks again, --Mobeen Azhar
(In reply to comment #16) > Soenke Dibbern, thank you for the patch. > I had already given up on the issue and ported the application to PHP5, which > does not exhibit the issue. > > Thanks again, > --Mobeen Azhar > yes, and doesn't exhibit many other odd problems, that's one of the reasons why distro only have PHP 5.1.x now.
fixed and tracked in bug #164845