MySQL Bugs: #1814: Linking dynamic binaries with static nss flags

Bug #1814	Linking dynamic binaries with static nss flags
Submitted:	12 Nov 2003 7:25	Modified:	29 Jun 2007 16:42
Reporter:	Alexandre Nunes	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	4.1.1-current-bk	OS:	Linux (Linux)
Assigned to:	Kent Boortz	CPU Architecture:	Any

Description:
If a system's glibc has been compiled with --enable-static-nss, then MySQL's configure adds -lnss_files -lnss_dns etc. to global link flags, which are propagated to the dynamic linking, inclusive, and also end up appearing on mysql_config --libs.

While it's OK to some extent, it's not polite nor recommendable behaviour. For instance, with current building procedures, even libmysqlclient.so is made to depend on these libraries.

NSS was designed so that the dynamic modules, when in use, could be unloaded and replaced by modified versions. It's my case here.

It's sometimes necessary, to link static binaries with these flags. I don't see a problem with that. I would suggest you only add the static nss flags to those targets linked with all-static or something.

How to repeat:
compile/link with a (native) glibc previously build by using --enable-static-nss on a linux system.

Suggested fix:
To suppress the nss flags from any dynamic linking sequence, including any libraries.

Also do not include nss flags in mysql_config script (except where strictly necessary, i.e. --libmysqld-libs or to those targets which are only static).

The user should know what he's doing if he has a compiled a static-nss libc, so it's his responsability to adjust accordingly on other non-standard situations.