Description
Attila Tóth
2010-11-03 21:54:44 UTC
And it doesn't start with message: denied RWX mprotect of /usr/lib/mysql/libmystrings.so.0.0.0 by /usr/bin/my_print_defaults[ my_print_defaul:22039] uid/euid:0/0 gid/egid:0/0, parent /sbin/runscript.sh[runscript.sh:22036] uid/euid:0/0 gid/egid:0/0 (In reply to comment #1) > And it doesn't start with message: > denied RWX mprotect of /usr/lib/mysql/libmystrings.so.0.0.0 by > /usr/bin/my_print_defaults[ > my_print_defaul:22039] uid/euid:0/0 gid/egid:0/0, parent > /sbin/runscript.sh[runscript.sh:22036] uid/euid:0/0 gid/egid:0/0 > Sorry, that I forgot to mention it. The same happens on my systems (Pentium M, Athlon MP) as well. Both running x86 Hardened Gentoo. *** Bug 344173 has been marked as a duplicate of this bug. *** Created attachment 253259 [details]
emerge info for hardened/linux/x86/10.0
The same happens here and the problem is always reproducibile only with gcc-4.4.5:4.4 (see attachments for my emerge info)
why was this assigned directly to me instead of the mysql herd? Can somebody please test with: EPATCH_EXCLUDE='02040_all_embedded-library-shared-5.1.50.patch' Added to the ebuild? Created attachment 253335 [details]
emerge --info for a hardened box
I got no textrels warnings on my hardened box - including the shared lib patch.
* Applying various patches (bugfixes/updates) ...
* 01050_all_mysql_config_cleanup-5.1.41.patch ...
[ ok ]
* 02040_all_embedded-library-shared-5.1.50.patch ...
[ ok ]
I'm confirming too, without '02040_all_embedded-library-shared-5.1.50.patch' mysql works on hardened kernel. Just to be clear, I got no warnings whatsoever about textrels and mysql was built with the shared lib patch. Furthermore it starts and runs here. (In reply to comment #9) > Just to be clear, I got no warnings whatsoever about textrels and mysql was > built with the shared lib patch. Furthermore it starts and runs here. > Just to let you know this symptom may be related to hardened. Are you using hardened? Which version of gcc are you running? Mine: gcc version 4.4.5 (Gentoo Hardened 4.4.5 p1.0, pie-0.4.5) gcc version 4.4.4 (Gentoo Hardened 4.4.4-r2 p1.2, pie-0.4.5) Created attachment 253343 [details]
emerge --info on a second hardened box
On this second box:
gcc version 4.4.5 (Gentoo Hardened 4.4.5 p1.0, pie-0.4.5)
~ $ qlop -l sys-devel/gcc | tail -n 1
Tue Oct 26 06:33:02 2010 >>> sys-devel/gcc-4.4.5
~ $ qlop -l dev-db/mysql | tail -n 1
Fri Nov 5 15:32:14 2010 >>> dev-db/mysql-5.1.52
No textrels warnings on mysql as well and mysql starts and runs.
On the 1st box: $ gcc-config -l [1] x86_64-pc-linux-gnu-4.3.4 [2] x86_64-pc-linux-gnu-4.3.4-hardenednopie [3] x86_64-pc-linux-gnu-4.3.4-vanilla [4] x86_64-pc-linux-gnu-4.4.4 * [5] x86_64-pc-linux-gnu-4.4.4-hardenednopie [6] x86_64-pc-linux-gnu-4.4.4-hardenednopiessp [7] x86_64-pc-linux-gnu-4.4.4-hardenednossp [8] x86_64-pc-linux-gnu-4.4.4-vanilla On the 2nd box: ~ $ gcc-config -l [1] x86_64-pc-linux-gnu-4.3.5 [2] x86_64-pc-linux-gnu-4.3.5-hardenednopie [3] x86_64-pc-linux-gnu-4.3.5-vanilla [4] x86_64-pc-linux-gnu-4.4.5 * [5] x86_64-pc-linux-gnu-4.4.5-hardenednopie [6] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp [7] x86_64-pc-linux-gnu-4.4.5-hardenednossp [8] x86_64-pc-linux-gnu-4.4.5-vanilla I think this textrel only affect x86 and not amd64 (In reply to comment #12) > Created an attachment (id=253343) [details] > emerge --info on a second hardened box > > On this second box: > gcc version 4.4.5 (Gentoo Hardened 4.4.5 p1.0, pie-0.4.5) > > ~ $ qlop -l sys-devel/gcc | tail -n 1 > Tue Oct 26 06:33:02 2010 >>> sys-devel/gcc-4.4.5 > ~ $ qlop -l dev-db/mysql | tail -n 1 > Fri Nov 5 15:32:14 2010 >>> dev-db/mysql-5.1.52 > > No textrels warnings on mysql as well and mysql starts and runs. > Please note your different version of mysql on the second box. Summing up: mysql-5.1.51 and hardened gcc-4.4.5 might form a deadly combination. (In reply to comment #14) > I think this textrel only affect x86 and not amd64 > Bad news. I've opened an upstream bug. While it might be a x86 specific hardened issue... (In reply to comment #14) > I think this textrel only affect x86 and not amd64 > Yup, confirmed. Works for me on my amd64 box but not on my x86 box. Can some one post the info from scanelf -qT on that lib that have the textrel? http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml Part 3 x86,gcc-4.4.5: # scanelf -qT /usr/lib/mysql/libmystrings.so.0.0.0 libmystrings.so.0.0.0: tab_jisx0208_uni22 [0xD985] in (optimized out: previous .strstr_end) [0xD97B] /usr/lib/mysql/libmystrings.so.0.0.0 objdump-> 0000d97b <strinstr>: d97b: 55 push %ebp d97c: 89 e5 mov %esp,%ebp d97e: ff 75 0c pushl 0xc(%ebp) d981: ff 75 08 pushl 0x8(%ebp) d984: e8 fc ff ff ff call d985 <strinstr+0xa> d989: 83 c4 08 add $0x8,%esp d98c: 09 c0 or %eax,%eax d98e: 74 04 je d994 <si_99> d990: 2b 45 08 sub 0x8(%ebp),%eax d993: 40 inc %eax Is it what You ask? (In reply to comment #19) > x86,gcc-4.4.5: > # scanelf -qT /usr/lib/mysql/libmystrings.so.0.0.0 > libmystrings.so.0.0.0: tab_jisx0208_uni22 [0xD985] in (optimized out: > previous .strstr_end) [0xD97B] > /usr/lib/mysql/libmystrings.so.0.0.0 > > objdump-> > 0000d97b <strinstr>: > d97b: 55 push %ebp > d97c: 89 e5 mov %esp,%ebp > d97e: ff 75 0c pushl 0xc(%ebp) > d981: ff 75 08 pushl 0x8(%ebp) > d984: e8 fc ff ff ff call d985 <strinstr+0xa> > d989: 83 c4 08 add $0x8,%esp > d98c: 09 c0 or %eax,%eax > d98e: 74 04 je d994 <si_99> > d990: 2b 45 08 sub 0x8(%ebp),%eax > d993: 40 inc %eax > > Is it what You ask? > yes thank you Part of strings-x86.s # Find a substring in string, return index # Arg: str,search .globl strinstr .type strinstr,@function strinstr: pushl %ebp movl %esp,%ebp pushl 12(%ebp) # search pushl 8(%ebp) # str call strstr add $8,%esp or %eax,%eax jz si_99 # Not found, return NULL sub 8(%ebp),%eax # Pos from start inc %eax # And first pos = 1 si_99: popl %ebp ret .strinstr_end: .size strinstr,.strinstr_end-strinstr # Make a string of len length from another string # Arg: dst,src,length # ret: end of dst This is my proposal for fix, but I'm too ill to guarantee it will work :( Change the function to: # Find a substring in string, return index # Arg: str,search .globl strinstr .type strinstr,@function strinstr: pushl %ebp movl %esp,%ebp #ifdef __PIC__ # undef __i686 /* gcc define gets in our way */ pushl %ebx call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx #endif pushl 12(%ebp) # search pushl 8(%ebp) # str #ifdef __PIC__ call strstr@PLT #else call strstr #endif add $8,%esp or %eax,%eax jz si_99 # Not found, return NULL sub 8(%ebp),%eax # Pos from start inc %eax # And first pos = 1 si_99: popl %ebx popl %ebp ret To the end of the file add: #ifdef __PIC__ .section .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx .type __i686.get_pc_thunk.bx,@function __i686.get_pc_thunk.bx: movl (%esp), %ebx ret #endif Zorry passed this patch on to me. It seems to do the trick: --- a/strings/strings-x86.s 2010-09-13 13:42:10.000000000 +0000 +++ b/strings/strings-x86.s 2010-11-05 22:11:23.000000000 +0000 @@ -293,7 +293,7 @@ movl %esp,%ebp pushl 12(%ebp) # search pushl 8(%ebp) # str - call strstr + call *%1 add $8,%esp or %eax,%eax jz si_99 # Not found, return NULL @@ -301,6 +301,9 @@ inc %eax # And first pos = 1 si_99: popl %ebp ret + : + : "r" (&strsr) + : .strinstr_end: .size strinstr,.strinstr_end-strinstr (In reply to comment #23) > Zorry passed this patch on to me. It seems to do the trick: > > > --- a/strings/strings-x86.s 2010-09-13 13:42:10.000000000 +0000 > +++ b/strings/strings-x86.s 2010-11-05 22:11:23.000000000 +0000 > @@ -293,7 +293,7 @@ > movl %esp,%ebp > pushl 12(%ebp) # search > pushl 8(%ebp) # str > - call strstr > + call *%1 > add $8,%esp > or %eax,%eax > jz si_99 # Not found, return NULL > @@ -301,6 +301,9 @@ > inc %eax # And first pos = 1 > si_99: popl %ebp > ret > + : > + : "r" (&strsr) > + : > .strinstr_end: > .size strinstr,.strinstr_end-strinstr > You guys are extremely fast. The proposed patch works for me! Hi, this patch has a typo and for me at least means that I'm unable to compile the .s file (standalone, need to be said). This patch solves the typo, but still results in failure: --- a/strings/strings-x86.s 2010-09-13 13:42:10.000000000 +0000 +++ b/strings/strings-x86.s 2010-11-05 22:11:23.000000000 +0000 @@ -293,7 +293,7 @@ movl %esp,%ebp pushl 12(%ebp) # search pushl 8(%ebp) # str - call strstr + call *%1 add $8,%esp or %eax,%eax jz si_99 # Not found, return NULL @@ -301,6 +301,9 @@ inc %eax # And first pos = 1 si_99: popl %ebp ret + : + : "r" (&strstr) + : .strinstr_end: .size strinstr,.strinstr_end-strinstr Instead I wrote this other that makes use of a local label to force a relative argument for call: diff -r -u a/strings/strings-x86.s b/strings/strings-x86.s --- a/strings/strings-x86.s 2010-11-06 04:55:39.912000351 +0100 +++ b/strings/strings-x86.s 2010-11-06 04:57:55.317000353 +0100 @@ -248,6 +248,7 @@ .type strstr,@function strstr: +strstr_begin: #PIC doesn't seems to work well otherwise pushl %edi pushl %esi movl 12(%esp),%esi # str @@ -293,7 +294,7 @@ movl %esp,%ebp pushl 12(%ebp) # search pushl 8(%ebp) # str - call strstr + call strstr_begin # This should make the call relative fixing PIC issues add $8,%esp or %eax,%eax jz si_99 # Not found, return NULL This, aside from compiling for me, also is way more efficient as we don't need to load up a register with the strstr address. I also wrote a small test code for the strinstr function which will be attached on next comment. To compile just use gcc and link with the library. Created attachment 253363 [details]
Small C file to test that the strinstr function works properly.
Created attachment 253365 [details, diff]
Patch, in a more fancy fashion to be used.
Well a bit more of insight, looks like gcc is screwing things here way to much. This: "d984: e8 fc ff ff ff call d985 <strinstr+0xa>" Means do a call to a function placed at 0x989 - 0x4 which is an invalid op. I don't know enough of the linking process to know if that's the way in which addresses to be modified are detected in TEXTRELed code, mayb it is, anyway it's very ugly. My patched code in exchange results in this: 164: e8 bb ff ff ff call 124 <strstr> Which uses a correct relative address and should fix the problem. (In reply to comment #28) > Well a bit more of insight, looks like gcc is screwing things here way to much. > > This: > "d984: e8 fc ff ff ff call d985 <strinstr+0xa>" > Means do a call to a function placed at 0x989 - 0x4 which is an invalid op. I > don't know enough of the linking process to know if that's the way in which > addresses to be modified are detected in TEXTRELed code, mayb it is, anyway > it's very ugly. > > My patched code in exchange results in this: > 164: e8 bb ff ff ff call 124 <strstr> > > Which uses a correct relative address and should fix the problem. > I have to apologize. When I got back with success after testing zorry's proposal, I haven't tested the function itself. Now I tested klondike's patch, and I can confirm, that it gives a dryer, safer feeling. Dissecting the code looks well as it was demonstrated above. So I vote for klondike's. Very well thank you. Zorry's code should work (couldn't check anyway as I don't have an x86 environment to try though). The assembly posted by Zorry is from the original .s file and I could also hit it. Now If somebody could upload the compiled code with Zorry patch I'd be grateful as I'd like to see what magic the compiler does there. (In reply to comment #30) > Now If somebody could upload the compiled code with Zorry patch I'd be grateful > as I'd like to see what magic the compiler does there. On x86, the Zorry works *because* it contains a syntax error and because "strings/strings-x86.s" is used by configure to determine if assembly code should be enabled. Since "as", when fed with this file, returns an error state during configure, assembly functions aren't used at all ... strings-x86.s: Assembler messages: strings-x86.s:296: Error: bad register name `%1' strings-x86.s:304: Error: junk at end of line, first unrecognized character is `:' strings-x86.s:305: Error: junk at end of line, first unrecognized character is `:' strings-x86.s:306: Error: junk at end of line, first unrecognized character is `:' Just a short notice, this is still present in 5.1.52. (In reply to comment #14) > I think this textrel only affect x86 and not amd64 > I can confirm this. dev-db/mysql-5.1.51 compiles on amd64 without TEXTRELs. On x86 it produces some. sys-devel/binutils-2.20.1-r1 sys-devel/gcc-4.4.4-r2 are installed on both systems. (In reply to comment #31) > (In reply to comment #30) > > Now If somebody could upload the compiled code with Zorry patch I'd be grateful > > as I'd like to see what magic the compiler does there. > > On x86, the Zorry works *because* it contains a syntax error and because > "strings/strings-x86.s" is used by configure to determine if assembly code > should be enabled. Since "as", when fed with this file, returns an error state > during configure, assembly functions aren't used at all ... > > strings-x86.s: Assembler messages: > strings-x86.s:296: Error: bad register name `%1' > strings-x86.s:304: Error: junk at end of line, first unrecognized character is > `:' > strings-x86.s:305: Error: junk at end of line, first unrecognized character is > `:' > strings-x86.s:306: Error: junk at end of line, first unrecognized character is > `:' > > > Even if i fix the typo we can't use that fix for the asm need to be inlined to support extended asm so we have two ways to go. 1. The patch with the GLOBAL_OFFSET_TABLE fix. 2. The patch with intern function that is not global. zorry/hardened: could you just pick which of them I should use, and then I'll do a revbump with it added to the patchset. (In reply to comment #34) > (In reply to comment #31) > > (In reply to comment #30) > > > Now If somebody could upload the compiled code with Zorry patch I'd be grateful > > > as I'd like to see what magic the compiler does there. > > > > On x86, the Zorry works *because* it contains a syntax error and because > > "strings/strings-x86.s" is used by configure to determine if assembly code > > should be enabled. Since "as", when fed with this file, returns an error state > > during configure, assembly functions aren't used at all ... > > > > > Even if i fix the typo we can't use that fix for the asm need to be inlined > to support extended asm so we have two ways to go. > 1. The patch with the GLOBAL_OFFSET_TABLE fix. > 2. The patch with intern function that is not global. > What is your opinion about klondike's patch? It seems to be clean. Created attachment 253771 [details, diff]
GOT based patch
Just for the record: When speaking of patch 2 I'll refer to "patchmysqlpic.patch" and when speaking of patch 1 to "mysql.patch". patch 1 obsoletes comment #22 as it was broken, pushing %ebx but never poping it back which would result in odd behaviour (most probably segfaults). Now a bit off discussion between patches 1 of 2. Patch 2 basically forces the compiler to do a local call avoiding any other fuss. Is simple and elegant but means that strstr overloads done by other libraries won't work which in turn means that it may be rejected by upstream for that reason. Patch 1 is a bit uglier, first renames the .s file to .S to enable the preprocessor and uses a correct call stack storing the GOT table address in %ebx and calling strstr@plt. This is the way in which gcc -fPIC -m32 -S generates the functions, so it should work as long as the plt stub is generated properly and the call address is correctly updated. Both patches work when linked with test.c but patch 1 may not work when used on a library if the plt stub is not generated properly. As I don't have a reasonably fast x86 machine with gentoo to test the patches I can't ensure if this will work. One last note to compile test.c use "gcc test.c -lmystrings". Personally I'll go for 1 and I think Zorry also (he will answer later I suppose). (In reply to comment #38) > Just for the record: When speaking of patch 2 I'll refer to > "patchmysqlpic.patch" and when speaking of patch 1 to "mysql.patch". > > patch 1 obsoletes comment #22 as it was broken, pushing %ebx but never poping > it back which would result in odd behaviour (most probably segfaults). > > Now a bit off discussion between patches 1 of 2. > > Patch 2 basically forces the compiler to do a local call avoiding any other > fuss. Is simple and elegant but means that strstr overloads done by other > libraries won't work which in turn means that it may be rejected by upstream > for that reason. > > Patch 1 is a bit uglier, first renames the .s file to .S to enable the > preprocessor and uses a correct call stack storing the GOT table address in > %ebx and calling strstr@plt. This is the way in which gcc -fPIC -m32 -S > generates the functions, so it should work as long as the plt stub is generated > properly and the call address is correctly updated. > > Both patches work when linked with test.c but patch 1 may not work when used on > a library if the plt stub is not generated properly. As I don't have a > reasonably fast x86 machine with gentoo to test the patches I can't ensure if > this will work. > > One last note to compile test.c use "gcc test.c -lmystrings". > > Personally I'll go for 1 and I think Zorry also (he will answer later I > suppose). > Mein gros Gott! You guys are hilarious! I'm currently using patch 2. The server's load is very low. No problem popped up. I start testing patch 1. The only drawback of patch 1 is that the S file should be synchronized to changes introduced to the original s file, if both files will happen to be present upstreams in the future. Thanks again! Created attachment 253789 [details, diff]
GOT based patch, applied before prepared and fixing the exectuable stack
Fixing a few things after some comments from zorry.
Created attachment 253791 [details, diff]
GOT based patch, applied before prepared and fixing the exectuable stack (The .section code is moved to the beggining as suggested by Zorry, although it shouldn't matter)
Created attachment 253801 [details, diff]
GOT based patch, applied before prepared and fixing the exectuable stack (Misunderstood Zorry, moved again to the end).
Created attachment 253809 [details, diff]
Fix the textrel in libmystrings.so
Have clened klondike patch.
it pass the test.c check
I leav the strings.s as it is, do what you want wiht that file.
Thank klondike for the fix and help.
Created attachment 253813 [details, diff]
Same patch for mariadb
The same patch as before.
Just for the record all those patches are released on the public domain.
Same issues here: /usr/bin/my_print_defaults: error while loading shared libraries: /usr/lib/mysql/libmystrings.so.0: cannot make segment writable for relocation: Permission denied; MySQL NOT started (1) [1436166.714909] grsec: From 172.16.17.10: denied RWX mprotect of /usr/lib/mysql/libmystrings.so.0.0.0 by /usr/sbin/mysqld[mysqld:31011] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 (In reply to comment #45) > Same issues here: > > /usr/bin/my_print_defaults: error while loading shared libraries: > /usr/lib/mysql/libmystrings.so.0: cannot make segment writable for relocation: > Permission denied; MySQL NOT started (1) > > [1436166.714909] grsec: From 172.16.17.10: denied RWX mprotect of > /usr/lib/mysql/libmystrings.so.0.0.0 by /usr/sbin/mysqld[mysqld:31011] > uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 > I didn't modify ebuild of 5.1.51, so I guess without patches. BTW, while all of you are working to fix mysql-5.1.51, maybe this version of mysql should be masked at hardened profile? It would prevent from pain in the a...:) No more work to do on the hardened side but wait for the patch to be merged. Anyway I concur that masking 5.1.51 and 5.1.52 would be a good idea. I got this problem as well. Since hardened profile is supposed to be "more secure" I guess it would be nice to have this fscking mysql-5.1.51 masked on that profile. It's more than a month that this is a well known bug but it is still marked as stable when, actually, it is not. Please fix this situation soon. (In reply to comment #49) > Please fix this situation soon. There will be a 5.1.52-r1 and 5.1.53 released at the same time, when I have fixed bug 344885, that needs to go in at the same time. (In reply to comment #50) > (In reply to comment #49) > > Please fix this situation soon. > There will be a 5.1.52-r1 and 5.1.53 released at the same time, when I have > fixed bug 344885, that needs to go in at the same time. > It was reported upstream: http://bugs.mysql.com/bug.php?id=57998 Might get accepted. However USE=mariadb may still will have to be taken care of. 5.1.52-r1 and 5.1.53 are in the tree now. Please test, so that we can stabilize one of them (ideally .53, as it has some replication fixes not present in .52). To comment 51 if it is accepted in mysql then there is no need to push it on MariaDB. dev-db/mysql-5.1.53 is working fine on x86 hardened please test 5.1.56 and reopen if needed. Created attachment 271197 [details]
buildlog mysql-5.1.56
I tried to emerge dev-db/mysql-5.1.56 but it doesn't even build: http://bugs.gentoo.org/attachment.cgi?id=271197 # emerge --info =dev-db/mysql-5.1.56 Portage 2.1.9.42 (hardened/linux/x86, gcc-4.4.5, libc-0-r0, 2.6.37-hardened-r7 i686) ================================================================= System Settings ================================================================= System uname: Linux-2.6.37-hardened-r7-i686-QEMU_Virtual_CPU_version_0.13.0-with-gentoo-1.12.14 Timestamp of tree: Tue, 26 Apr 2011 07:30:01 +0000 app-shells/bash: 4.1_p9 dev-lang/python: 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 sys-kernel/linux-headers: 2.6.36.1 virtual/os-headers: 0 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl bash-completion berkdb bzip2 cli cracklib crypt cups cxx dri gdbm gpm hardened iconv modules mudflap ncurses nls nptl nptlonly openmp pam pcre perl pic pppd python readline session ssl sysfs tcpd test urandom x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 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 authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" 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="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 intel mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa via vmware nouveau" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY # emerge -pqv =dev-db/mysql-5.1.56 [ebuild U ] dev-db/mysql-5.1.56 [5.1.51] USE="community perl ssl test -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -pbxt -profiling (-selinux) -static -xtradb" There's something wrong on x86, see bug 364451. thx, it's working now. yes, it works Marking as fixed then. |