Summary: | media-libs/mesa-10.3.7[abi_x86_32] - ../../../../src/gallium/auxiliary/.libs/libgallium.a(tgsi_exec.o): In function `micro_imsb': tgsi_exec.c:(.text+0x1ac3): undefined reference to `__clrsbsi2' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | cache <c-h> |
Component: | [OLD] Library | Assignee: | Matt Turner <mattst88> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | multilib+disabled, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=539626 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 530652 | ||
Attachments: |
build.log.tar.xz
clr.c objdump output after clr.c compiling patch objdump output after clr.c compiling with -m32 |
Description
cache
2015-01-17 21:22:29 UTC
Created attachment 394220 [details]
build.log.tar.xz
Comment on attachment 394220 [details]
build.log.tar.xz
Why did you put a single file in a tar archive? It's entirely possible to compress a file without doing that.
Can you try mesa-10.4.2? (In reply to Chí-Thanh Christopher Nguyễn from comment #3) > Can you try mesa-10.4.2? I tried it. Same error. Anyway, mesa-10.4.2 from main tree do not have "openvg" USE and thus unusable for me as I am using BricsCAD 13 which want this library. Created attachment 394360 [details] clr.c The code in question is static INLINE unsigned util_last_bit_signed(int i) { #if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 407) && !defined(__INTEL_COMPILER) return 31 - __builtin_clrsb(i); #else if (i >= 0) return util_last_bit(i); else return util_last_bit(~(unsigned)i); #endif } It's using __builtin_clrsb if gcc is 4.7 or newer. If I compile this code with gcc-4.9.1 or 4.8.2 I see that it adds a __clrsbdi2 function into the linked binary that is called in place of __builtin_clrsb. I don't have gcc-4.7 to test it, but you're not using that either. Mesa should be using AX_GCC_BUILTIN in configure to test for this builtin, which it isn't. But also, I'm not sure the use of __builtin_clrsb is correct anyway. I'll handle this upstream. I've attached a C program. Could you compile it with 'gcc -O2 clr.c -o clr' and then attach the output of 'objdump -d clr' to this bug? (In reply to cache from comment #4) > (In reply to Chí-Thanh Christopher Nguyễn from comment #3) > > Can you try mesa-10.4.2? > > I tried it. Same error. Anyway, mesa-10.4.2 from main tree do not have > "openvg" USE and thus unusable for me as I am using BricsCAD 13 which want > this library. Wow, I didn't know anything actually used that. I'll pass that information along. The application only uses OpenVG? It can't use OpenGL? > I've attached a C program. Could you compile it with 'gcc -O2 clr.c -o clr' > and then attach the output of 'objdump -d clr' to this bug? No problem, attached. > The application only uses OpenVG? It can't use OpenGL? It uses OpenGL. My fail, sorry. Wrong interpretation of ldd output. But emerging mesa-10.4.2 failed with same error anyway as I wrote. Created attachment 394372 [details]
objdump output after clr.c compiling
Created attachment 394734 [details, diff]
patch
Whoops, I should have told you to compile clr.c with -m32. Could you post the objdump output of that?
Also, could you try this patch, either by adding it to your portage tree and modifying the ebuild to apply it, or by
ebuild mesa-10.4.2.ebuild prepare
<manually apply patch to /var/tmp/portage/media-libs/mesa/work/...>
ebuild mesa-10.4.2.ebuild compile
Created attachment 394768 [details]
objdump output after clr.c compiling with -m32
(In reply to Matt Turner from comment #8) > Whoops, I should have told you to compile clr.c with -m32. Could you post > the objdump output of that? Yep. Attached. > Also, could you try this patch, either by adding it to your portage tree and > modifying the ebuild to apply it, or by > > ebuild mesa-10.4.2.ebuild prepare > > <manually apply patch to /var/tmp/portage/media-libs/mesa/work/...> > > ebuild mesa-10.4.2.ebuild compile I'm doing this right now. Will send a reply after compiling end. pacho asked me to look at this bug wrt powerpc. I tested clr.c on ppc and ppc64 with gcc-4.8.3 and it works fine there. Do I need to check for pre 4.7? Rather than using the gcc builting, its probably safer for mesa to just code this function. According to the doc, it takes and int (signed) and "Returns the number of leading redundant sign bits in x, i.e. the number of bits following the most significant bit that are identical to it. There are no special cases for 0 or other values." This seems easy enough and would future proof the code against gcc's ever changing builtings. No need for AX_GCC_BUITLIN. (In reply to Anthony Basile from comment #11) > pacho asked me to look at this bug wrt powerpc. I tested clr.c on ppc and > ppc64 with gcc-4.8.3 and it works fine there. Do I need to check for pre > 4.7? > Never mind. pacho wanted me to look at another bug on ppc --- I was wondering why he wanted this? > Rather than using the gcc builting, its probably safer for mesa to just code > this function. According to the doc, it takes and int (signed) and "Returns > the number of leading redundant sign bits in x, i.e. the number of bits > following the most significant bit that are identical to it. There are no > special cases for 0 or other values." This seems easy enough and would > future proof the code against gcc's ever changing builtings. No need for > AX_GCC_BUITLIN. Ths comment still stands. (In reply to Matt Turner from comment #8) > Created attachment 394734 [details, diff] [details, diff] > patch > > Whoops, I should have told you to compile clr.c with -m32. Could you post > the objdump output of that? > > Also, could you try this patch, either by adding it to your portage tree and > modifying the ebuild to apply it, or by > > ebuild mesa-10.4.2.ebuild prepare > > <manually apply patch to /var/tmp/portage/media-libs/mesa/work/...> > > ebuild mesa-10.4.2.ebuild compile Sorry for long delay. Same error after aplying patch on mesa-10.4.2. @matt, did you had time to contact to upstream? Maybe they could help a bit on this :/ (this is the main blocker for the xorg stabilization and would be interesting to try to handle it or, at least, get help from them). Thanks a lot :) (In reply to Pacho Ramos from comment #14) > @matt, did you had time to contact to upstream? Maybe they could help a bit > on this :/ (this is the main blocker for the xorg stabilization and would be > interesting to try to handle it or, at least, get help from them). Thanks a > lot :) I am upstream, but without being able to reproduce the issue, I don't know what else I can do. I'll ask around. I'm going to send a patch to just remove the use of the built-in. Once it's upstream I'll add it to the ebuild. I've added the patch to the 10.3.7 and 10.4.3 ebuilds. I would really like to understand the cause of this problem though. cache, is there a chance I could SSH into your machine and reproduce the problem? (In reply to Matt Turner from comment #17) > I've added the patch to the 10.3.7 and 10.4.3 ebuilds. Where is "right" mesa-10.4.3 available? After layman -S && emerge --sync right now there is only mesa-10.4.2 in portage. My overlays are: bitcoin calculate mozilla perl-experimental rion sabayon science sunrise wavilen zugaina. > I would really like to understand the cause of this problem though. cache, > is there a chance I could SSH into your machine and reproduce the problem? Emm… This is my main working machine. Disk clone on KVM virtual machine with ssh access for you acceptable? I can prepare it within 1-2 days. The mesa-10.4.3.ebuild was committed Tue Feb 3 21:46:15 2015 UTC Check the timestamp of your tree according to "emerge --info", if it is earlier then you won't have it. (In reply to Matt Turner from comment #17) > I've added the patch to the 10.3.7 and 10.4.3 ebuilds. > > I would really like to understand the cause of this problem though. cache, > is there a chance I could SSH into your machine and reproduce the problem? mesa-10.4.3 compiled OK. Thank you. (In reply to cache from comment #18) > > I would really like to understand the cause of this problem though. cache, > > is there a chance I could SSH into your machine and reproduce the problem? > > Emm… This is my main working machine. Disk clone on KVM virtual machine with > ssh access for you acceptable? I can prepare it within 1-2 days. Sure, that would work fine. I'll email you with my SSH key. (In reply to Matt Turner from comment #21) > Sure, that would work fine. I'll email you with my SSH key. Still need it after succesfull compiling mesa-10.4.3? (In reply to cache from comment #22) > (In reply to Matt Turner from comment #21) > > Sure, that would work fine. I'll email you with my SSH key. > > Still need it after succesfull compiling mesa-10.4.3? Yes, the patch is 10.4.3 just disables the use of the __builtin, avoiding the problem but not fixing it. (In reply to Matt Turner from comment #23) > > Yes, the patch is 10.4.3 just disables the use of the __builtin, avoiding > the problem but not fixing it. Ok, I'll prepare VM ASAP. (In reply to cache from comment #24) > (In reply to Matt Turner from comment #23) > > > > Yes, the patch is 10.4.3 just disables the use of the __builtin, avoiding > > the problem but not fixing it. > > Ok, I'll prepare VM ASAP. Friendly reminder :) |