Some patch that was added between dev-db/mysql-5.1.52 and dev-db/mysql-5.1.52-r1 results in the addition of the --32 flag if mysql is built for ABI=x86. This is not a valid compiler flag. I am using the "multilib" overlay, that's why the attempt to build mysql for ABI=x86. Reproducible: Always Steps to Reproduce:
Copy-and-paste from #gentoo-multilib-overlay IRC log: (17:39:34) vlooe: /usr/portage/profiles/arch/amd64/make.defaults:ASFLAGS_x86="--32" (17:42:07) vlooe: patrakov: mysql tries to pass the ASFLAGS to gcc instead to as (18:11:46) Tommy[D]: patrakov: as vlooe said, that patch changed the build behaviour to directly give ASFLAGS to gcc instead of as or prefixed with the flag indicating, that the flag is for as
oops
The ONLY change mentioning ASFLAGS between 5.1.52 and 5.1.52-r1 is in 07340_all_mariadb_hardened_x86_strings.patch, which is NOT applied at all, as it's for mariadb only. And that's actually CCASFLAGS, and the change is so that the pre-processor handles the asm code... If you want to check for yourself: # git diff mysql-extras-20101104-1842Z..mysql-extras-20101128-2122Z in the mysql-extras repo. Please provide: - emerge --info -v - complete build log for both 5.1.52 and 5.1.52-r1 - config.log files for both 5.1.52 and 5.1.52-r1 Then reopen with the info required. I hope that gimpel@sonnenkinder.org is the correct CC contact for the multilib overlay. I don't see any explicit contact address for the group on the GitHub page. Some form of mail alias registered on Bugzilla would be useful...
Additionally, try to trace it down to one of the patches that changed between those two releases. Just exclude them until you can isolate the problem...
Created attachment 256593 [details] emerge --info -v emerge --info -v is too big for a comment, so attached
Created attachment 256597 [details] config.log from 5.1.52-r1, for 64 bits Compilation produces two config.log files, one for 64 bits and one for 32 bits. Attaching the 64-bit one.
Created attachment 256599 [details] config.log from 5.1.52-r1, for 32 bits and now for 32 bits
Created attachment 256600 [details] Full build log for 5.1.52-r1 This log contains a successful 64-bit build and a failed 32-bit one.
I won't attach a successful build log because the problem is already clear enough. The problematic patch is 07340_all_mysql_hardened_x86_strings.patch, because it adds a new .S (asm with preprocessor) file. This file is then tried to be compiled with this command: $(AM_V_CPPAS)$(LTCPPASCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $< where LTCPPASCOMPILE = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=compile $(CCAS) $(DEFS) \ $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(AM_CCASFLAGS) $(CCASFLAGS) and CCASFLAGS = -O2 -march=core2 -fomit-frame-pointer -fno-strict-aliasing -pipe -m32 -DHAVE_ERRNO_AS_DEFINE=1 -fno-strict-aliasing --32 -Wa,--noexecstack CCASFLAGS come from configure.in, it contains this buggy line: CCASFLAGS="$CCASFLAGS $ASFLAGS" Let me patch it locally and report back.
Removing the buggy line from configure.in helps. Even the --32 flag gets correctly passed to the assembler (but, obviously, it comes from the compiler defaults, not from ASFLAGS). So you may want to do something like this instead (untested): for flag in $ASFLAGS ; do $CCASFLAGS="$CCASFLAGS -Wa,$flag" ; done It is too late here for me to test this new line, but you can do that on your own. Just add some dummy flag like --32 to your ASFLAGS on x86 and see if the build fails.
Francisco, Magnus: Your security patch from bug 344031 has broken compiling on multilib. Please provide a new version. I suggest based on the version in comment #10, after you've tested that it doesn't break hardened again.
Maybe I'm doing it wrong but: ABI="x86" ebuild /usr/portage/dev-db/mysql/mysql-5.1.52-r1.ebuild compile compiled the source without any issue
(On the hardened amd64 profile with multilib)
Gah, definitely something more than the ABI has to have changed, otherwise it will compile nicely, maybe the chost?
(In reply to comment #3) > I hope that gimpel@sonnenkinder.org is the correct CC contact for the multilib > overlay. I don't see any explicit contact address for the group on the GitHub > page. Some form of mail alias registered on Bugzilla would be useful... > I am the main contact for multilib-portage and the main person doing the work behind it. So you can either CC/ask me or CC the multilib alias, which includes some users maintaining the eclass variant.
Created attachment 256739 [details, diff] Patch to fix the configure.in file Managed to reproduce on a x86 machine with some help from Tommy[D] as a result here is a patch :D Mariadb will probably need either this or a similar patch, will try to write that too.
Created attachment 256743 [details, diff] Corrected patch Did a mistake and generate the diff reversely, this is the correct one.
Created attachment 256763 [details, diff] Same for mariadb Same for mariadb
tommy/multilib: still pending on you testing the new patch (comment 17/18) from klondike.
(In reply to comment #19) > tommy/multilib: still pending on you testing the new patch (comment 17/18) from > klondike. I applied the patch from comment 17 and was able to crosscompile dev-db/mysql-5.1.53 with USE="community ssl". The patch from comment 18 failed to apply. Since i dont know, if it needs something else in addition like some additional USE flag enabled, i did not investigate further. I have also seen some dropped configure options: * QA Notice: Unrecognized configure options: * * configure: WARNING: unrecognized options: --with-plugindir, --without-plugin-example, --without-plugin-ibmdb2i, --without-plugin-partition, --without-plugin-federated, --without-plugin-ndbcluster, --without-plugin-pbxt * configure: WARNING: unrecognized options: --with-plugindir, --without-plugin-example, --without-plugin-ibmdb2i, --without-plugin-partition, --without-plugin-federated, --without-plugin-ndbcluster, --without-plugin-pbxt
please test 5.1.56 and reopen if needed.
Created attachment 270811 [details] build.log-5.1.56 I have build error (both gcc-4.4.5 and gcc-4.5.2): i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../include -I../include -I../include -I../sql -O2 -march=native -mfpmath=sse -pipe -s -DHAVE_ERRNO_AS_DEFINE=1 -fno-strict-aliasing -fno-omit-frame-pointer -DUNIV_LINUX -DUNIV_LINUX -MT replace.o -MD -MP -MF .deps/replace.Tpo -c -o replace.o replace.c mv -f .deps/replace.Tpo .deps/replace.Po /bin/sh ../libtool --preserve-dup-deps --tag=CC --mode=link i686-pc-linux-gnu-gcc -O2 -march=native -mfpmath=sse -pipe -s -DHAVE_ERRNO_AS_DEFINE=1 -fno-st rict-aliasing -fno-omit-frame-pointer -DUNIV_LINUX -DUNIV_LINUX -Wl,-O1 -Wl,--as-needed -rdynamic -o replace replace.o -lstdc++ ../mysys/libmysys.la ../db ug/libdbug.la ../strings/libmystrings.la -L/usr//lib -lz -lpthread -lcrypt -lnsl -lm -lpthread libtool: link: i686-pc-linux-gnu-gcc -O2 -march=native -mfpmath=sse -pipe -s -DHAVE_ERRNO_AS_DEFINE=1 -fno-strict-aliasing -fno-omit-frame-pointer -DUNIV_LINU X -DUNIV_LINUX -Wl,-O1 -rdynamic -o replace replace.o -Wl,--as-needed -lstdc++ ../mysys/.libs/libmysys.a -lpthread -lpthread -lpthread -lpthread ../dbug/.lib s/libdbug.a -lpthread -lpthread -lpthread -lpthread ../strings/.libs/libmystrings.a -lpthread -lpthread -lpthread -lpthread -L/usr//lib -lz -lpthread -lcrypt -lnsl -lm -lpthread replace.o: In function `main': replace.c:(.text+0x1c72): undefined reference to `strend' ../mysys/.libs/libmysys.a(mf_tempfile.o): In function `create_temp_file': mf_tempfile.c:(.text+0x51): undefined reference to `strnmov' ../mysys/.libs/libmysys.a(mf_dirname.o): In function `convert_dirname': mf_dirname.c:(.text+0x92): undefined reference to `strmake' ../mysys/.libs/libmysys.a(my_symlink.o): In function `my_realpath': my_symlink.c:(.text+0x67): undefined reference to `strmake' ../mysys/.libs/libmysys.a(mf_pack.o): In function `system_filename': mf_pack.c:(.text+0xd9): undefined reference to `strmake' ../mysys/.libs/libmysys.a(mf_pack.o): In function `unpack_dirname': [...]
For me, mysql-5.1.56 builds fine, so this x86-specific ASFLAGS bug is fixed. Marcin Mirosław: your build failure is not caused by passing invalid arguments to the assembler, so it is a different bug. Please file it separately.
