Calm down. Stop spinning, and ignoring advice you've been given. If it works from command line and not cgi, stop guessing, and figure out what the differences are, its that simple. Write a program to load DBI/mysql, connect, disconnect, then dump @INC, %INC, %ENV, %::... and compare the output from commandline and from cgi. If you can't figure it out, post the code and output here.
| [reply] |
Sage advice. Thanks.
Trust me, I'm not ignoring anything. I've already determined that DBI/mysql can connect, that the XS-modules are being loaded... from the correct locations (i.e. the site's local CPAN). This much I now know. The CGI-environment, only, throws the _login mesage. I have examined INC, and ENV, (what's %::?) very closely throughout.
The crux of the question is: what in the heck is different about this environment vs. the command line?” I can see that I have lots of XS-modules that are working just fine.
As I read perldoc DBI::DBD, I see that “The variables $DBD::Driver::{dr|db|st}::imp_data_size are not defined here, but in the XS code, because they declare the size of certain C structures.“, this is obviously a very-direct clue when considered in light of the messages that “imp_data_size was unexpectedly expanded.” I see that DBI.so and mysql.so both contain this symbol, viz: grep -rilw imp_data_size . | grep \.so | xargs grep imp_data_size
BTW, there is method to my bulldog-madness. I'm “chatting” on this thread partly because I well know that there are interested-parties. These are not written to be “rants.” Anyone who (follows|has followed) in this rocky path will (see|have seen) these same rocks. When this thread finally reaches its successful conclusion, I hope it will be useful both in its final-post and in the posts leading up to it. That's my intention, anyway.
| |
Well you missed something. Provide your test code and output.
| [reply] |