When trying to build on amd64 with abi_x86_32 enabled (in emul-linux-x86-* and also per package setting as suggested by emerge), I found that qtsql can't be compiled with the summary error. Last lines are: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libmysqlclient_r.so when searching for -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../lib32/libmysqlclient_r.so when searching for -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/../lib32/libmysqlclient_r.so when searching for -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../libmysqlclient_r.so when searching for -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib32/libmysqlclient_r.so when searching for -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libmysqlclient_r.so when searching for -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lmysqlclient_r /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/libz.so when searching for -lz collect2: error: ld returned 1 exit status Makefile:116: recipe for target '../../../../plugins/sqldrivers/libqsqlmysql.so' failed locate libmysqlclient_r.so gives: /usr/lib32/libmysqlclient_r.so /usr/lib32/libmysqlclient_r.so.18 /usr/lib32/libmysqlclient_r.so.18.0.0 /usr/lib64/libmysqlclient_r.so /usr/lib64/libmysqlclient_r.so.18 /usr/lib64/libmysqlclient_r.so.18.0.0 and libz: /lib32/libz.so.1 /lib32/libz.so.1.2.8 /lib64/libz.so.1 /lib64/libz.so.1.2.8 /usr/lib32/libz.so /usr/lib64/libz.so So I guess the problem is not in the graphite2 ebuild but something about it not being able to find it. Reproducible: Always
Created attachment 391540 [details] build log
I think it could be better to cc multilib herd also, since it seems to affect only when builing with multilib option
I've been watching the logs, and I saw in compilation line the following: -L/usr/lib32/mysql, but according to locate, mariadb installed the lib directly under /usr/lib32, not under mysql subfolder. Can this be the cause?
Another test, it builds with -mysql flag so problem is definitelly caused by multilib build with mysql support.
Among the linking errors of the -m32 build there is: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib32/libmysqlclient_r.so when searching for -lmysqlclient_r This is strange... why is it incompatible? Please rebuild mysql/mariadb and try again.
Rebuild both, zlib and mariadb with same result. This is very strange, because the only 2 things that fails to build in multilib has in common the can't find -lz (this one, and bug #532408) I think I discovered what is happenning: This is correct zero stormbyte # file /lib/libz.so.1.2.8 /lib/libz.so.1.2.8: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped zero stormbyte # file /lib32/libz.so.1.2.8 /lib32/libz.so.1.2.8: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped But I discovered that the one that is under /usr/lib{32,64} is not actually a symlink, nor a library, it is text file containing: cat /usr/lib32/libz.so /* GNU ld script Since Gentoo has critical dynamic libraries in /lib, and the static versions in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we run into linking problems. This "fake" dynamic lib is a linker script that redirects the linker to the real lib. And yes, this works in the cross- compiling scenario as the sysroot-ed linker will prepend the real path. See bug http://bugs.gentoo.org/4411 for more info. */ OUTPUT_FORMAT ( elf32-i386 ) GROUP ( /lib32/libz.so.1 ) So if compilation is, according to the message, trying to find libz.so inside /usr/lib32, it will find the text file and not the shared library. May it be the cause?
Oh, I think I found the cause: file /usr/lib32/libmysqlclient.so.18.0.0 /usr/lib32/libmysqlclient.so.18.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Why is the 64bit libmysqlclient library is stored in lib32 ?? Probably a bug in mariadb ebuild?
Should I post a new bug against mariadb/mysql and block this one, or simply change bug topic?
Do you have mysql or mariadb installed? Please post the `emerge -pv` for that package.
@mysql-bugs guys, see comment #7
I have mariadb installed according to (looking which one is going to be rebuilt): emerge -pv dev-db/mysql dev-db/mariadb These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-db/mariadb-10.0.15-r1 USE="community embedded extraengine pam perl ssl xml -cluster -debug -jemalloc -latin1 -max-idx-128 -minimal -odbc -oqgraph -profiling (-selinux) -sphinx -static -static-libs -systemtap -tcmalloc {-test} -tokudb" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild N ] dev-db/mysql-5.6.22 USE="community perl ssl -cluster -debug -embedded -extraengine -jemalloc -latin1 -max-idx-128 -minimal -profiling (-selinux) -static -static-libs -systemtap -tcmalloc {-test}" ABI_X86="32 (64) (-x32)" 33.799 KiB [blocks B ] dev-db/mariadb ("dev-db/mariadb" is blocking dev-db/mysql-5.6.22) [blocks B ] dev-db/mysql ("dev-db/mysql" is blocking dev-db/mariadb-10.0.15-r1)
Created attachment 391968 [details] mariadb build log
(In reply to David Carlos Manuelda from comment #7) > Oh, I think I found the cause: > > file /usr/lib32/libmysqlclient.so.18.0.0 > /usr/lib32/libmysqlclient.so.18.0.0: ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV), dynamically linked, stripped > > Why is the 64bit libmysqlclient library is stored in lib32 ?? Probably a bug > in mariadb ebuild? Works here: grknight@tetsusaiga ~ $ file /usr/lib32/libmysqlclient.so.18.0.0 /usr/lib32/libmysqlclient.so.18.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=19ceacf961bb7db61dfa11f70dab7b9b5e19f70e, stripped grknight@tetsusaiga ~ $ eix -e mariadb [I] dev-db/mariadb Available versions: [M](~)5.1.67{tbz2}[1] [M](~)5.2.14{tbz2}[1] [M](~)5.3.12[1] 5.5.39{tbz2}[1] 5.5.40-r1 5.5.40-r1[1] (~)10.0.15{tbz2} (~)10.0.15{tbz2}[1] (~)10.0.15-r1 [M](~)10.1.0_alpha{tbz2}[1] [M](~)10.1.2_alpha[1] [M]**9999[1] {big-tables bindist cluster +community cracklib debug embedded extraengine galera innodb-lz4 innodb-lzo jemalloc latin1 libevent max-idx-128 minimal odbc oqgraph pam pbxt +perl profiling selinux sphinx ssl sst-rsync sst-xtrabackup static static-libs systemtap tcmalloc test tokudb xml ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 10.0.15-r1(02:33:21 PM 12/15/2014)(community embedded extraengine jemalloc latin1 oqgraph pam perl profiling ssl tokudb xml -cluster -debug -max-idx-128 -minimal -odbc -selinux -sphinx -static -static-libs -systemtap -tcmalloc -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32") Homepage: http://mariadb.org/ Description: An enhanced, drop-in replacement for MySQL [1] "mysql" /usr/local/portage/layman/mysql
(In reply to David Carlos Manuelda from comment #12) > Created attachment 391968 [details] > mariadb build log I don't see any -m32 in this build log...
Created attachment 391970 [details] emerge --info
(In reply to Davide Pesavento from comment #14) > (In reply to David Carlos Manuelda from comment #12) > > Created attachment 391968 [details] > > mariadb build log > > I don't see any -m32 in this build log... Yes, that is the problem, just that I don't know why it is not using CXXFLAGS_x86 or adding the -m32 flag. Only this (and graphite2) exhibits this bad behavior when building multilib. Anyways I've added emerge --info output if it helps, because here it is not working :(
*** This bug has been marked as a duplicate of bug 532408 ***
