Here is what we have found while working on the 0.2.1 version of Escapade: Because Escapade is not open source, and is in the following sense similar to prepackaged Perl and PHP systems, Escapade is distributed as a static binary (because of library incompatibility issues among various Linux systems) on Linux which was linked with the current MySQL client library *at compile time*. This produces a rather interesting scenario when run on a system which specifies different compile-time options than as distributed. The problem arises when MySQL is configured and built with mysql.sock configured to be in a non-standard place (we usually find it in /var/lib/mysql/mysql.sock) on another machine, and the Escapade binary is run. The DBOPEN statement will fail with the complaint that /tmp/mysql.sock doesn't exist. Checking /tmp verified that, indeed, there is no mysql.sock file in that directory. What's going on? It turns out that, because MySQL needs to know where to put mysql.sock at runtime, and because all the MySQL client programs need to know where this is when they run, too, the socket file value as configured at compile time is compiled into the runtime client library. When mysql_connect() or mysql_real_connect() is called, it "knows" where to go to connect to mysql.sock, because it was specified at compile time. So what? Since the runtime library knows where mysql.sock is, all the client programs should run just fine, right? Well, sure - if your client isn't linked statically! If it is, whatever value that was compiled into the runtime library will be linked into the static binary - which may be wrong on the target system where the static binary is installed. The problem can be solved and therefore becomes a non-issue when /etc/my.cnf (or ~/my.cnf, etc.) exists and contains the socket file specification, because adding a call to mysql_options() will pick up the information in my.cnf. The only problem with this is that /etc/my.cnf isn't mandatory, nor is it apparently installed when MySQL itself is installed. If /etc/my.cnf (or path variations) don't exist, there is no way for the static client to figure out where the socket file is, and therefore the mysql_connect or mysql_real_connect call fails, while a dynamically linked program will succeed. The obvious solution is to force, in the client library, for my.cnf to exist, correctly configured, in a published place. Any other ideas on how to solve this problem? I've already mentioned why relinking as a dynamic binary isn't feasible. Thanks in advance :) -- Ed Carp, N7EKG - [EMAIL PROTECTED] - 214/341-4420 - http://www.pobox.com/~erc Squished Mosquito, Inc. Internet Applications Development Escapade Server-Side Scripting Language Development Team http://www.squishedmosquito.com Pensacola - Dallas - Dresden - London --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
