>i've built mysql 5.0.21 threadsafe -- hence, the link target >needs to be the _reentrant_ libmysqlclient_r

No. If you don't build a threaded client, you don't need to link against the reentrant client libraries.

hi mike,

of course.

sorry, i should have specified rather than assumed it would be obvious ...

i have built php "--with-tsrm-pthreads".

same issue, one vs both libs linked.

This configure flag does not enable thread safety.

mike,

great. rather than dribbles of info, can you, then, please specify what configuration option does and how to end up linked agaist only the right/single library?

bottom line is i'm looking for thread-safe php + mysql, linked against libmysqlclient_r.

let's just say the documentation hasn't been, at least for me, forthcoming on the matter ...

The switch to enable thread safety is --enable-maintainer-zts.  The name suggests though, that you shoulnd't use it unless you've got a really good reason to do so.


Now about the reentrancy issues of the mysql extensions:
None of ext/mysql, ext/mysqli, ext/pdo_mysql check for the reentrant version of the client library if ZTS is enabled.

ext/mysql though, calls mysql_thread_init() and mysql_thread_end() and thus cause sort of a deadlock if linked against libmysqlclient_r.

Just a recap, no fix yet.

> The switch to enable thread safety is --enable-maintainer-zts.

thx for the clarification.

> that you shoulnd't use it unless you've got a really good reason to do so.

understood.  i'm exploring (non-production, yet) 'playing nice' with apache worker mpm, reentrant mysql libs, and some threaded functionality we're working on ...

> Now about the reentrancy issues of the mysql extensions:
> ...
> Just a recap, no fix yet.

fair nuf.

fwiw, given your comments, doing:

b4 config:

	perl -pi -e 's/mysqlclient\,/mysqlclient_r\,/g' ext/pdo_mysql/config.m4
	perl -pi -e 's/mysqlclient\./mysqlclient_r\./g' ext/pdo_mysql/config.m4
	perl -pi -e 's/libmysqlclient.lib/libmysqlclient_r.lib/g' ext/mysql/mysql.mak
	perl -pi -e 's/LIBNAME=mysqlclient\n/LIBNAME=mysqlclient_r\n/g' ext/mysql/config.m4

then:
	glibtoolize
	buildconf

and, after config, b4 make:

	perl -pi -e 's/mysqlclient /mysqlclient_r /g' Makefile
	perl -pi -e 's/mysqlclient\n/mysqlclient_r\n/g' Makefile

seems, so far to give me a stable/executable build, linked uniquely/solely against lmysqlclient_r ... of course, i haven't done any serious functional testing as yet.

let me know if/how i can play 'guinea pig' ...

richard

No bug here.
It works exactly the way it should.

Set status back to "Open".

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

mike,

thanks.

in which branch is the "fix"?  51, 52 &/or 6?

5.2 (and 6 except PDO)

hi mike,

thanks for the CVS pointer ...

in 5.2cvs DL, i note:

% grep mysqlclient `grep -rlni mysqlclient .`
...
  ./ext/mysql/config.m4:    MYSQL_LIBNAME=mysqlclient_r
  ./ext/mysql/config.m4:    MYSQL_LIBNAME=mysqlclient
  ./ext/mysql/mysql.mak:LIBRARY = $(MYSQL_DIR)/lib/libmysqlclient.lib
  ./ext/mysqli/config.m4:  MYSQL_LIB_NAME='mysqlclient'
  ./ext/mysqli/config.m4:    MYSQL_LIB_NAME='mysqlclient_r'
  ./ext/pdo_mysql/config.m4:  str="$PDO_MYSQL_DIR/$1/libmysqlclient*"
  ./ext/pdo_mysql/config.m4:      PDO_MYSQL_LIBNAME=mysqlclient_r
  ./ext/pdo_mysql/config.m4:      PDO_MYSQL_LIBNAME=mysqlclient


which looks like you've added conditionals in the requisite config.m4's ...

how about the reference in ./ext/mysql/mysql.mak ?

	# Library files
	LIBRARY = $(MYSQL_DIR)/lib/libmysqlclient.lib

needed to change?

richard

> looks like you've added conditionals

Of course.

> how about the reference in ./ext/mysql/mysql.mak

I have no idea, this is some ancient Netware stuff.

> I have no idea, this is some ancient Netware stuff.

Netware? jeesh ... it still around ;-)

if that's the case, I don't care ... & I'm done.

thanks!

onward ...

richard