Created attachment 328050 [details] build log At an unstable Gentoo I upgraded mysql - emerged adviced me to run "emerge @preserved-rebuild" - which yields into this error : checking for mcrypt_module_open in -lmcrypt... yes checking for MSSQL support via FreeTDS... no checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... /var/run/mysqld/mysqld.sock checking for mysql_close in -lmysqlclient_r... no checking for mysql_error in -lmysqlclient_r... no configure: error: mysql configure failed. Please check config.log for more information.
n22 ~ # emerge --info =dev-lang/php-5.4.8 Portage 2.1.11.31 (default/linux/x86/10.0, gcc-4.7.2, glibc-2.16.0, 3.6.5 i686) ================================================================= System Settings ================================================================= System uname: Linux-3.6.5-i686-Intel-R-_Core-TM-_i5-2540M_CPU_@_2.60GHz-with-gentoo-2.2 Timestamp of tree: Fri, 02 Nov 2012 08:15:01 +0000 ld GNU ld (GNU Binutils) 2.23 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/cmake: 2.8.9-r1 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.2 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.4 sys-devel/binutils: 2.23 sys-devel/gcc: 4.7.2 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo toralf ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--autounmask=n --keep-going=y --nospinner --tree --deep --quiet-build" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs compress-build-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict test test-fail-continue unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en en_GB" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl apache2 berkdb bzip2 cli cracklib crypt cups cxx dri fam fastbuild gdbm gmp gpm iconv ipv6 logrotate mmx modules mudflap mysql mysqli ncurses nls nptl openmp pam pcre pppd readline session sse sse2 sse3 ssl ssse3 tcpd threads unicode userlocales webmail x86 xml zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="access actions alias auth_basic auth_digest authn_anon authn_core authn_dbd authn_dbm authn_default authn_file authz_core authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi compat dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so socache_shmcb speling status unique_id unixd userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB" PHP_TARGETS="php5-4" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= dev-lang/php-5.4.8 was built with the following: USE="apache2 berkdb bzip2 cli crypt ctype fileinfo filter gdbm gmp hash iconv ipv6 json mysql mysqli nls phar posix readline session simplexml ssl test threads tokenizer unicode xml xsl zlib -bcmath -calendar -cdb -cgi -cjk -curl -curlwrappers -debug -doc -embed -enchant -exif -firebird -flatfile -fpm -frontbase -ftp -gd -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap -ldap-sasl -libedit -mhash -mssql -mysqlnd -oci8-instant-client -odbc -pcntl -pdo -pic -postgres -qdbm -recode (-selinux) -sharedmem -snmp -soap -sockets -spell -sqlite3 -sybase-ct -sysvipc -tidy -truetype -wddx -xmlreader -xmlrpc -xmlwriter -xpm -zip"
> configure: error: mysql configure failed. Please check config.log for more information ...
configure:60969: checking for MySQL support configure:61005: result: yes configure:61014: checking for specified location of the MySQL UNIX socket configure:61029: result: /var/run/mysqld/mysqld.sock configure:61213: checking for mysql_close in -lmysqlclient_r configure:61238: x86_64-pc-linux-gnu-gcc -o conftest -I/usr/include -march=core2 -O2 -pipe -pthread -D_REENTRANT -L/usr/lib64 -Wl,-O1 -Wl,--as-needed confte$ /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lmysqlclient_r collect2: ld returned 1 exit status configure:61238: $? = 1 configure: failed program was: | /* confdefs.h */ and configure:61458: checking for mysql_error in -lmysqlclient_r configure:61483: x86_64-pc-linux-gnu-gcc -o conftest -I/usr/include -march=core2 -O2 -pipe -pthread -D_REENTRANT -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -Wl,-r$ /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lmysqlclient_r collect2: ld returned 1 exit status configure:61483: $? = 1 configure: failed program was: | /* confdefs.h */
Created attachment 328062 [details] config.log /var/tmp/portage/dev-lang/php-5.4.8/work/sapis-build/cli/config.log This is the only config.log found ]% emerge --info Portage 2.2.0_alpha142 (default/linux/amd64/10.0, gcc-4.6.3, glibc-2.16.0, 3.6.4-gentoo x86_64) ================================================================= System uname: Linux-3.6.4-gentoo-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-gentoo-2.2 Timestamp of tree: Fri, 02 Nov 2012 07:15:01 +0000 ld GNU ld (GNU Binutils) 2.23 ccache version 3.1.8 [disabled] app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/ccache: 3.1.8 dev-util/cmake: 2.8.9-r1 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.2 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.12.4 sys-devel/binutils: 2.23 sys-devel/gcc: 4.5.4, 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo digimed Installed sets: @cloudprintdeps, @temp ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/env.d /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/init.d /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/mnt/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical --jobs --load-average 10" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.heanet.ie/pub/gentoo/ http://gentoo.blueyonder.co.uk ftp://gentoo.blueyonder.co.uk/mirrors/gentoo ftp://ftp.easynet.nl/mirror/gentoo/" LANG="en_GB" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_GB" MAKEOPTS="-j16 -l10" PKGDIR="/mnt/portage/packages/marvin" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--timeout=500 --progress" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/mnt/portage/local" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow amd64 apache2 bzip2 cli cracklib crypt cups curl cxx dbus dri fam foomaticdb fortran ftp gd gdbm gmp gnutls iconv idn imap jpeg logrotate maildir mbox mmx modules mudflap multilib mysql ncurses netboot nptl openmp pcre png ppds pppd readline session snmp sse sse2 ssl svg tcpd threads unicode usb vhosts xml zlib zsh-completion" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" FOO2ZJS_DEVICES="hp1020 hp1022" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON
So: 1. 'emerge -1pv dev-db/mysql' for your useflags 2. check if libmysqlclient_r gets built/installed
Same bug here. emerge -pv mysql [ebuild R ] dev-db/mysql-5.5.28 USE="berkdb community perl ssl -cluster -debug -embedded -extraengine -jemalloc -latin1 -max-idx-128 -minimal -profiling (-selinux) -static -systemtap -tcmalloc {-test}" 0 kB libmysqlclient_r gets built and resides in /usr/lib{32,64}/mysql/
Hmm..., the macro detecting mysql (ext/mysql/config.m4 - MYSQL_LIB_CHK to be specific) looks a bit fishy - it seems it could detect that location of libmysqlclient_r, if the check ran in the opposite order. In dev-db/mysql-5.1.62-r1, this lib was simply in /usr/lib.
Happens also with dev-lang/php-5.3.18. libmysqlclient_r files are in /usr/lib64/mysql/ but *not* in /usr/lib32/mysql/. The versions before (libmysqlclient_r.so.16.0.0) are in both. There are also (old) symlinks in /usr/lib32/ pointing to /usr/lib32/mysql - but as said, not for the new libmysqlclient.so.18.0.0, only the old ones.
(In reply to comment #7) > In dev-db/mysql-5.1.62-r1, this lib was simply in /usr/lib. isn't there always a symlink lib -> lib{32,64}. that shouldn't be a problem then
Same with dev-db/mariadb-5.5.28
OK, I need to correct myself: libs are in /usr/lib/mysql/ for dev-db/mysql-5.1.62-r1 already - the stuff in /usr/lib are just symlinks. But comment 8 suggests that ebuild/upstream build system no longer creates symlinks in /usr/lib. Now, an interesting test would be removing old symlinks - perhaps they interfere with proper detection. Though it's odd, that they were not removed during emerge.
Removing the old files and symlinks allows php to build here rm /usr/lib64/libmysqlclient_r.so.16 rm /usr/lib64/mysql/libmysqlclient_r.so.16*
Removing old libs fixes php compilation for me: $ rm /usr/lib64/libmysqlclient_r.so.16 /usr/lib64/mysql/libmysqlclient_r.so.16 /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 But deleting preserved libs is not a good practice, so I think the ebuild should be fixed.
This is affecting me even after I removed all libmysql...16. I also ran `lafilefixer --justfixit` just in case. I do have some libmysql files with 16 in /usr/lib32 from emul-linux-x86-db. Maybe that's a problem?
My configure log shows: configure:62354: x86_64-pc-linux-gnu-gcc -o conftest -I/usr/include -march=native -O2 -pipe -pthread -D_REENTRANT -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -Wl,-rpath,/usr -L/usr conftes /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lmysqlclient_r It looks like mysql-5.5.28 only installs /usr/lib/libmysqlclient, but not /usr/lib/libmysqlclient_r, which is used here. Running the following commands fixes php for me, too. ln -s mysql/libmysqlclient_r.so.18.0.0 libmysqlclient_r ln -s mysql/libmysqlclient_r.so.18.0.0 libmysqlclient_r.so.18 ln -s mysql/libmysqlclient_r.so.18.0.0 libmysqlclient_r.so.18.0 ln -s mysql/libmysqlclient_r.so.18.0.0 libmysqlclient_r.so.18.0.0 Does that mean that mysql should install these or that php should find it in the subdirectory?
(In reply to comment #15) > It looks like mysql-5.5.28 only installs /usr/lib/libmysqlclient, but not > /usr/lib/libmysqlclient_r, which is used here. But that's not a problem. On a vanilla system I emerged dev-db/mysql-5.5.28. After that my system looked like yours: /usr/lib64/libmysqlclient -> mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so -> mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so.18 -> mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so.18.0 -> mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so.18.0.0 -> mysql/libmysqlclient.so.18.0.0 /usr/lib64/mysql/libmysqlclient.a /usr/lib64/mysql/libmysqlclient.so -> libmysqlclient.so.18 /usr/lib64/mysql/libmysqlclient.so.18 -> libmysqlclient.so.18.0.0 /usr/lib64/mysql/libmysqlclient.so.18.0.0 /usr/lib64/mysql/libmysqlclient_r.a -> libmysqlclient.a /usr/lib64/mysql/libmysqlclient_r.so -> libmysqlclient.so /usr/lib64/mysql/libmysqlclient_r.so.18 -> libmysqlclient.so /usr/lib64/mysql/libmysqlclient_r.so.18.0.0 -> libmysqlclient.so /usr/lib64/mysql/libmysqlservices.a but emerging dev-lang/php-5.3.18 wasn't a problem. The problem comes up, when PHP detects multiple libmysqlclient versions. To reproduce the issue: 0) Vanilla system 1) Emerge dev-db/mysql-5.1.62-r1 2) Now emerge something which depends on libmysqlclient (for example mail-mta/postfix or dev-lang/php with mysql USE flag) 3) Now, update dev-db/mysql Your will get the expected message, that some libraries are preserved: >>> No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 127 info files. !!! existing preserved libs: >>> package: dev-db/mysql-5.5.28 * - /usr/lib64/libmysqlclient_r.so.16 * - /usr/lib64/mysql/libmysqlclient_r.so.16 * - /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 * used by /usr/lib64/php5.3/bin/php (dev-lang/php-5.3.17) * - /usr/lib64/libmysqlclient.so.16 * - /usr/lib64/mysql/libmysqlclient.so.16 * - /usr/lib64/mysql/libmysqlclient.so.16.0.0 * used by /usr/lib64/perl5/vendor_perl/5.16.1/x86_64-linux/auto/DBD/mysql/mysql.so (dev-perl/DBD-mysql-4.20.0) * used by /usr/libexec/postfix/anvil (mail-mta/postfix-2.9.4) * used by /usr/libexec/postfix/bounce (mail-mta/postfix-2.9.4) * used by 29 other files Use emerge @preserved-rebuild to rebuild packages using these libraries * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. But running "emerge @preserved-rebuild" will now fail, when it comes to dev-lang/php (note: mail-mta/postfix will re-emerge without any problems!). My conclusion is: There is a problem with PHP's configure script. When you dig into it, you will see, that it detects BOTH libmysqlclient versions in the first step (the configure output will list two checking for libmysqlclient lines, on a system with just one version, you will see only one line, but testing the lib will fail (I assume that the testing part doesn't really support testing multiple versions). Another way to reproduce: 1) Go to a Debian system. 2) Install any mysql version from repository 3) Now put a previous libmysqlclient into /usr/lib... 4) Run PHP's configure script. It will fail like it is failing on Gentoo systems... Temporary fix: Make sure that PHP will just find ONE libmysqlclient version.
@comment 16: minor correction - the problem lies in the unfortunate mix of preserve-libs and php detection scheme. The check is for existence and readability of a file, not if it it's by chance a dead link - chances are that's the case that hits you.
(In reply to comment #13) > Removing old libs fixes php compilation for me: > $ rm /usr/lib64/libmysqlclient_r.so.16 > /usr/lib64/mysql/libmysqlclient_r.so.16 > /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 > > But deleting preserved libs is not a good practice, so I think the ebuild > should be fixed. /me wonders whether this is now a good/adviceable work around or not till the ebuild is fixed
(In reply to comment #18) > (In reply to comment #13) > > Removing old libs fixes php compilation for me: > > $ rm /usr/lib64/libmysqlclient_r.so.16 > > /usr/lib64/mysql/libmysqlclient_r.so.16 > > /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 > > > > But deleting preserved libs is not a good practice, so I think the ebuild > > should be fixed. > > /me wonders whether this is now a good/adviceable work around or not till > the ebuild is fixed The ebuild is correct, the problem is that the check does (on x86) something alike to for i in /usr/lib /usr/lib/mysql ; do for j in `echo $i/libmysqlclient{,_r}.*` ; do if test -r $j; then MYSQL_LIB_DIR=$i break 2 fi done done That works pretty well, if only standard links of mysql exist, but most likely preserved-libs skews the result. Check 'echo /usr/lib/libmysqlclient_r.*' and compare with 'ls -l /usr/lib/libmysqlclient_r.*' to see if that's really the case of broken links.
I do have at an unstable x86 currently: n22 ~ # ls -l /usr/lib/libmysqlclient_r.* lrwxrwxrwx 1 root root 32 Oct 1 20:17 /usr/lib/libmysqlclient_r.so.16 -> mysql/libmysqlclient_r.so.16.0.0 n22 ~ # ls -l /usr/lib/mysql/libmysql* -rw-r--r-- 1 root root 3469104 Nov 2 10:30 /usr/lib/mysql/libmysqlclient.a lrwxrwxrwx 1 root root 16 Nov 2 10:30 /usr/lib/mysql/libmysqlclient_r.a -> libmysqlclient.a lrwxrwxrwx 1 root root 17 Nov 2 10:30 /usr/lib/mysql/libmysqlclient_r.so -> libmysqlclient.so lrwxrwxrwx 1 root root 26 Oct 1 20:17 /usr/lib/mysql/libmysqlclient_r.so.16 -> libmysqlclient_r.so.16.0.0 -rwxr-xr-x 1 root root 1540284 Oct 1 20:16 /usr/lib/mysql/libmysqlclient_r.so.16.0.0 lrwxrwxrwx 1 root root 17 Nov 2 10:30 /usr/lib/mysql/libmysqlclient_r.so.18 -> libmysqlclient.so lrwxrwxrwx 1 root root 17 Nov 2 10:30 /usr/lib/mysql/libmysqlclient_r.so.18.0.0 -> libmysqlclient.so lrwxrwxrwx 1 root root 20 Nov 2 10:30 /usr/lib/mysql/libmysqlclient.so -> libmysqlclient.so.18 lrwxrwxrwx 1 root root 24 Nov 2 10:30 /usr/lib/mysql/libmysqlclient.so.18 -> libmysqlclient.so.18.0.0 -rwxr-xr-x 1 root root 2964396 Nov 2 10:29 /usr/lib/mysql/libmysqlclient.so.18.0.0 -rw-r--r-- 1 root root 3226 Nov 2 10:30 /usr/lib/mysql/libmysqlservices.a n22 ~ # echo /usr/lib/libmysqlclient_r.* /usr/lib/libmysqlclient_r.so.16
@comment 20: OK, so it's bit more complicated than I initially thought, but basically the same. Looks like mysql no longer creates the symlinks in /usr/lib, but the check gets confused by the old link in /usr/lib and fails to pass '-L/usr/lib/mysql' to a following check, which in turn fails. Unless mysql maintainer can be convinced to create those links anyway, this seems to basically be a WONTFIX, with a workaround of removing /usr/lib/libmysqlclient_r.so.16 symlink.
@ comment #21: > Unless mysql maintainer can be convinced to create those links anyway, this > seems to basically be a WONTFIX, with a workaround of removing > /usr/lib/libmysqlclient_r.so.16 symlink. There is no LINK problem. The mysql maintainer can do nothing to FIX this problem. The problem is, that PHP's configure script doesn't handle multiple libmysqlclient* libraries properly. Someone should create a bug at bugs.php.net. In the meantime: Make sure that PHP will only detect one library. For example move the preserved library to another location. After emerging PHP, you can move it back.
(In reply to comment #22) > @ comment #21: > > Unless mysql maintainer can be convinced to create those links anyway, this > > seems to basically be a WONTFIX, with a workaround of removing > > /usr/lib/libmysqlclient_r.so.16 symlink. > > There is no LINK problem. The mysql maintainer can do nothing to FIX this > problem. > I both agree and disagree: I don't think mysql maintainer should do a thing, unless there are other major packages affected, but at the same time I don't think php maintainer should do a thing about a transition problem of a different package. > The problem is, that PHP's configure script doesn't handle multiple > libmysqlclient* libraries properly. Someone should create a bug at > bugs.php.net. > :roll: This check handles a proper installation of mysql libs just fine and mysql upstream doesn't seem to support side by side installations of headers are a different matter. It's preserve-libs that's the problem here - it preserves enough for the programs to work, but it may create failures in corner cases such as this one.
(In reply to comment #23) > > There is no LINK problem. The mysql maintainer can do nothing to FIX this > > problem. > > > I both agree and disagree: I don't think mysql maintainer should do a thing, > unless there are other major packages affected, but at the same time I don't > think php maintainer should do a thing about a transition problem of a > different package. Please tell us what you think the mysql maintainer could do, to fix this problem. Creating "missing" links? This won't fix anything. And there is also nothing to fix. The current libraries are correct installed. Don't preserv libs? This is a portage feature, not coming from mysql. Only the PHP ebuild is failing. I really don't understand why you think the mysql maintainer should do something. It is not a mysql problem. All the other ebuilds, requiring mysql, are working well. They don't fail when detecting libmysqlclient* where multiple libmysqlclient* are found. > > The problem is, that PHP's configure script doesn't handle multiple > > libmysqlclient* libraries properly. Someone should create a bug at > > bugs.php.net. > > > :roll: This check handles a proper installation of mysql libs just fine No. PHP seems to detect multiple libmysqlclient* libraries (put n different libmysqlclient* libraries in /lib and you will see n "checking mysqlclient" lines in the configure output). But PHP doesn't seems to handle failed checks correct. For example: You have - libmysqlclient.so.15 - libmysqlclient.so.16 - libmysqlclient.so.18 libmysqlclient.so.15 and libmysqlclient.so.16 are just "preserved" libraries (in other words: incomplete mysqlclients). When checking libmysqlclient.so.15 and libmysqlclient.so.16, both checks SHOULD fail, because they are incomplete. So the check should end with checking libmysqlclient.so.18 which should pass. Finally, the complete check should pass now, because we have a working libmysqlclient. And here's the problem: It seems like, that PHP's configure doesn't check every detected version. At least, the working libmysqlclient.so.18 doesn't let the test pass. > mysql upstream doesn't seem to support side by side installations of > headers are a different matter. It's preserve-libs that's the problem here - > it preserves enough for the programs to work, but it may create failures in > corner cases such as this one. Yes and no. If the libmysqlclient.so.15 will pass, it would be wrong, when the new PHP would be build against the old - preserved - lib again. :) I will do some debugging later today. I expect that PHP isn't only checking for libmysqlclient.so like comment #19 says. If PHP would just check the libmysqlclient.so (no specific version), this should fix the problem in the right way.
@comment 24: :sigh: :roll: :sigh: as comment 20 shows, following links/libs were preserved: /usr/lib/mysql/libmysqlclient_r.so.16 /usr/lib/mysql/libmysqlclient_r.so.16.0.0 /usr/lib/libmysqlclient_r.so.16 The check in php would succeed, if /usr/lib/libmysqlclient_r.so was preserved too, but this is *exactly* the one that in the usual cases can't be preserved, as it would almost always be a merge conflict. New version of mysql didn't create it either, but a fresh mysql install wouldn't be affected by this problem. Therefore this problem affects only mysql *upgrade* path. Also, php has no business in touching the files it doesn't own, like i.e. mysql symlinks. So, there is no point in messing with a check, that works fine in the usual cases. My previous comments were a bit imprecise, as it's not exactly case of a broken links, but the point still stands - if mysql installed /usr/lib/libmysqlclient_r.so pointing to the *new* version, the check would would succeed and php would be linked against the new version too. Finally, those two "checking mysqlclient" checks you refer to, check for *different* functions (don't know mysql history well, enough, but that probably either an indirect version or a build option check). PS.: one thing mysql maintainer could consider, would be adding LDPATH="/usr/lib/mysql" entry to /etc/env.d.
Mhh... ok. You are right: Creating /usr/lib/libmysqlclient_r.so -> mysql/libmysqlclient_r.so.18.0.0 fixes the issue. Sorry.
(In reply to comment #26) > Mhh... ok. You are right: > > Creating > > /usr/lib/libmysqlclient_r.so -> mysql/libmysqlclient_r.so.18.0.0 > > fixes the issue. Sorry. That's a workaround. I'm attaching the correct fix now.
Created attachment 329780 [details, diff] Fix php configure failure with mysql in use.
(In reply to comment #28) > Created attachment 329780 [details, diff] [details, diff] > Fix php configure failure with mysql in use. issue solved at my system
Created attachment 329842 [details, diff] configure patch for 5.3.18
Created attachment 329844 [details] configure patch for 5.5.0-alpha1
2 new patched for 5.3.18 and 5.5.0-alpha1. These plus 5.4.8 are the only ebuilds that have the mysql config option set. 5.3.15 has the use flag, but no config option.
Scratch these 3 patches. Just found out that the post I got the "fix" from was bad. It works because its not compiling PHP with MySQL as there is no mysql-dir option in the configure file.
Any news on this? The issue in the ebuilds (at least :5.4 in ~amd64) are not fixed yet. I am also getting this build failure since some time. It seems there have been created working patches to fix this. Whats the reason not applying them?
(In reply to comment #34) > It seems there have been created working patches to fix this. Whats the > reason not applying them? There are not patches. See comment #33. As stated in comment #25 and confirmed by others, re-creating the "missing" symlink for libmysqlclient.so/libmysqlclient_r.so will fix it. But this is something the mysql maintainer should do, because with the next update of mysql, these links need to be updated again. So I guess this issue is assigned to the PHP maintainer at the moment. Don't know how we can assign it to mysql maintainer...
(In reply to comment #34) > Any news on this? > > The issue in the ebuilds (at least :5.4 in ~amd64) are not fixed yet. I am > also getting this build failure since some time. > > It seems there have been created working patches to fix this. Whats the > reason not applying them? There are no working patchsets here and the php checks work fine while system is not in the transient state. It seems mysql upstream decided to remove the additional links and given that there doesn't seem other packages were reported to have a similar problem, there should be no reason for mysql maintainer to take action.
(In reply to comment #36) > It seems mysql upstream decided to remove the additional links and given > that there doesn't seem other packages were reported to have a similar > problem, there should be no reason for mysql maintainer to take action. Well, most other packages will use libmysqlclient and *not* libmysqlclient_r. libmysqlclient_r was supposed to be thread-safe, but libmysqlclient and libmysqlclient_r were identical. So the mysql team decided to remove libmysqlclient_r to make clear that they don't really offer a thread-safe lib. For me it would be easier if the mysql maintainer would just add the symlink. This would add backward compatibility for applications, which still depend on libmysqlclient_r. When PHP is really the last application depending on libmysqlclient_r, we should patch the configure script and remove the check for libmysqlclient_r, so that PHP will always use libmysqlclient. Again: There is no libmysqlclient_r in MySQL anymore and there really wasn't a libmysqlclient_r at anytime, which was different from libmysqlclient. So removing the check for libmysqlclient_r should be safe. But if the mysql package would just maintain a symlink for backward compatibility, I would vote for that. You don't know all the packages, still depending on libmysqlclient_r...
Sorry for being somewhat missing in this issue. I do not think patching PHP is really the right way to go here since it is such a corner case, and it still only affects unstable arch. One way that could solve this would be to not use libmysql, but use mysqlnd instead (USE="mysqlnd").
It's not quite a corner case in the way you mean it - once mysql 5.5 hits stable, it will hit people there too, but only while the *old* symlinks are still present. Once those are gone, things will work as they're supposed to. @comment 37: unless I'm missing something (comment 20): /usr/lib/mysql/libmysqlclient_r.so.18 -> libmysqlclient.so the link is already there.
Created attachment 331258 [details, diff] This patch removes the libmysqlclient_r detection, so that PHP will always use libmysqlclient. (In reply to comment #38) > One way that could solve this would be to not use libmysql, but use mysqlnd instead (USE="mysqlnd"). *ACK*. Converting to mysqlnd would solve this problem, too. And personally I would recommend everyone to switch from mysqlclient to mysqlnd. But because most people will use mysql instead of mysqlnd (I think because they don't know about mysqlnd) this is a problem, which we need to fix. (In reply to comment #39) > @comment 37: unless I'm missing something (comment 20): > /usr/lib/mysql/libmysqlclient_r.so.18 -> libmysqlclient.so > > the link is already there. In /usr/lib/mysql - yes. But the detection will happen in /usr/lib - that's why I thought it is a problem in PHP's detection logic first. Anyway, I attached a patch which will just remove the check for libmysqlclient_r, so that PHP will always use libmysqlclient. As stated before, that's what currently happen and happen all the time, because there never was a thread-safe mysqlclient.
(In reply to comment #40) > *ACK*. Converting to mysqlnd would solve this problem, too. And personally I > would recommend everyone to switch from mysqlclient to mysqlnd. From http://dev.mysql.com/downloads/connector/php-mysqlnd/ : "As of PHP 5.4, the mysqlnd library is a php.net compile time default to all PHP MySQL extensions." So maybe it should be the same on gentoo. Enabling mysql or mysqli or pdo should also enable mysqlnd as a default USE flag, IMHO.
(In reply to comment #41) > (In reply to comment #40) > > From http://dev.mysql.com/downloads/connector/php-mysqlnd/ : > "As of PHP 5.4, the mysqlnd library is a php.net compile time default to all > PHP MySQL extensions." > > So maybe it should be the same on gentoo. > > Enabling mysql or mysqli or pdo should also enable mysqlnd as a default USE > flag, IMHO. Unfortunately the only way to solve this is to reverse the USE flag. I.e instead of having a mysqlnd USE flag, you would need a no-mysqlnd USE flag or libmysqlclient USE flag that will disable mysqlnd and use libmysqlclient instead. In my mind, this can be done for both php 5.4 and php 5.3 as I have no knowledge of any use case where you want to use libmysqlclient instead of mysqlnd.
(In reply to comment #42) > Unfortunately the only way to solve this is to reverse the USE flag. I.e > instead of having a mysqlnd USE flag, you would need a no-mysqlnd USE flag > or libmysqlclient USE flag that will disable mysqlnd and use libmysqlclient > instead. > > In my mind, this can be done for both php 5.4 and php 5.3 as I have no > knowledge of any use case where you want to use libmysqlclient instead of > mysqlnd. The libmysqlclient USE flag (disabled by default) is IMHO the best way to follow. If you really know what you are doing, you can switch back to libmysqlclient by enabling this flag. +1 for me
The source of the change in MySQL/MariaDB is the move to change libmysqlclient_r to a symlink. This breaks the mysql_fx.eclass function mysql_lib_symlinks for other builds to reference. A true fix would be to deprecate this hacky function and add /usr/($libdir)/mysql to the so path. This may break a bunch of packages, but would not break anything using mysql_config helper like it should be.
I revbumped the 5.5 beta so that mysqlnd is enabled by default and you have to do USE="libmysqlclient" in order to not use mysqlnd. If it works as expected, I will add the same changes to the other slots. Then one would have to - have threads enabled for PHP, something one should not do - have libmysqlclient enabled, something one should not do in order to be affected by this.
# equery b libmysqlclient.so.16 * Searching for libmysqlclient.so.16 ... dev-db/mysql-5.1.67 (/usr/lib64/mysql/libmysqlclient.so.16 -> libmysqlclient.so.16.0.0) dev-db/mysql-5.1.67 (/usr/lib64/libmysqlclient.so.16 -> mysql/libmysqlclient.so.16.0.0) dev-db/mysql-5.1.67 (/usr/lib64/mysql/libmysqlclient.so.16.0.0) after upgradeing to dev-db/mariadb-5.5.31 (emerge mariadb) (~amd64) it replaces dev-db/mysql, removes it. But the libs mentioned in this bug above not removed. Maybe this is a bug in portage or somewhere else. Removing the old libs (they are no longer belongs to packes) manually fixes the compile problem!
I found the lib files was not mistakenly leaved in place, it's a feature indeed! http://wiki.gentoo.org/wiki/Preserve-libs The problem, without manually removing the preserved libs it is not possible to rebuild the package (to use the new libs)...
Did you run 'emerge -av @preserved-rebuild' after you emerged dev-db/mariadb? The libraries should be removed by portage, when the last package which was build against the previous dev-db/mysql version was rebuilt.
I've pushed into the tree some updates to the mysql eclasses that should help with this. Can anyone hitting this issue wait a few hours, sync and test if it still fails?
Is anyone still hitting this issue with the latest mysql/mariadb 5.5 ebuilds? @php: time to close as NEEDINFO?
I just hit the problem after upgrading from mariadb-5.2.14 to mariadb-5.5.33a. 'emerge -av @preserved-rebuild' failed at php-5.4.17 with that same mysql configure error.
At the same time, php:5.5 configures OK.
I have similar problem as Andreas, upgraded mysql-5.1.70 to mysql-5.5.32. Php-5.4.20 can't find lmysqliclient: checking for specified location of the MySQL UNIX socket... /var/run/mysqld/mysqld.sock checking for mysql_close in -lmysqlclient... no checking for mysql_error in -lmysqlclient... no configure: error: mysql configure failed. Please check config.log for more information.
Just hit the same problem, solved by removing "libmysqlclient" from my package.use file.
problem still present trying to emerge dev-lang/php-5.5.7
Created attachment 365676 [details] php 5.5.7 build.log
@ Renato: Is there a reason for using PHP 5.5.x with libmysql instead of mysqlnd (which is the default MySQL driver since PHP 5.4.x)? Maybe you never adjusted your PHP USE flags for newer versions?
which use flags are correct ? (In reply to Thomas D. from comment #57) > @ Renato: > Is there a reason for using PHP 5.5.x with libmysql instead of mysqlnd > (which is the default MySQL driver since PHP 5.4.x)? > > Maybe you never adjusted your PHP USE flags for newer version(In reply to Thomas D. from comment #57) > @ Renato: > Is there a reason for using PHP 5.5.x with libmysql instead of mysqlnd > (which is the default MySQL driver since PHP 5.4.x)? > > Maybe you never adjusted your PHP USE flags for newer versions?
No, there actually nothing *wrong* with your USE flags, but deprecated. E.g. PHP doesn't use libmysql anymore, upstream switched to mysqlnd as default MySQL driver a long time ago. Gentoo's PHP package maintainer is not going to fix this problem for current PHP versions because he agrees with upstream that you should use mysqlnd instead of libmysql (e.g. remove the "libmysqlclient" USE flag and your problem will be gone), see his comments in this bug. This will work until there's a reason you really need the old outdated MySQL driver. If this is the case, please share your use case but in most cases mysqlnd should work very well, because it is a drop-in replacement.
We've pushed some work in the mysql eclasses to the tree that should help with the libmysqlclient issues. I suggest closing this as FIXED or TESTREQUEST.
No further problems reported. I consider it fixed on both ends.
