MySQL extensions should link against thread safe client libs if built with ZTS

Bug #37630	MySQL extensions should link against thread safe client libs if built with ZTS
Submitted:	2006-05-29 15:54 UTC	Modified:	2006-06-01 20:05 UTC
From:	openmacnews at gmail dot com	Assigned:
Status:	Closed	Package:	MySQL related
PHP Version:	5.1.4	OS:	osx
Private report:	No	CVE-ID:	None

[2006-05-29 15:54 UTC] openmacnews at gmail dot com

Description:
------------
hi all,

i'm building php-5.1.4 from source on osx 10.4.6

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

if i configure php as:


setenv CPPFLAGS "-I/usr/local/mysql/include/mysql"
setenv LDFLAGS "-bind_at_load -L/usr/local/mysql/lib/mysql -lmysqlclient_r" 

./configure \
  ...
  --enable-pdo \
  --with-mysql=/usr/local/mysql \
  --with-mysql-sock=/var/Process \
  --with-pdo-mysql=/usr/local/mysql \
  --with-apxs2=/usr/local/apache2/sbin/apxs \
  ...

the build completes w/o error, BUT, resultant libs & bins are built linked against BOTH lmysqlclient_r AND lmysqlclient.

iiuc, this should NOT be the case.

to get around this, *prior* to 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

and after config, prior to *make*:

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

again, no errors, and the libs/bins are linked -- as expected -- against *only* the reentrant lib.


cheers,

richard

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2006-05-30 13:14 UTC] mike@php.net

>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.

[2006-05-30 15:44 UTC] openmacnews at gmail dot com

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.

[2006-05-30 16:22 UTC] mike@php.net

This configure flag does not enable thread safety.

[2006-05-30 16:34 UTC] openmacnews at gmail dot com

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 ...

[2006-05-31 17:58 UTC] mike@php.net

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.

[2006-05-31 19:41 UTC] openmacnews at gmail dot com

> 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

[2006-06-01 08:46 UTC] tony2001@php.net

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

[2006-06-01 13:22 UTC] mike@php.net

Set status back to "Open".

[2006-06-01 19:15 UTC] mike@php.net

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.

[2006-06-01 19:27 UTC] openmacnews at gmail dot com

mike,

thanks.

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

[2006-06-01 19:48 UTC] openmacnews at gmail dot com

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

[2006-06-01 20:00 UTC] mike@php.net

> 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.

[2006-06-01 20:05 UTC] openmacnews at gmail dot com

> 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