Sources Bugzilla – Bug 11875
'make' fails even though 'configure' is OK
Last modified: 2010-08-05 18:55:53 UTC
'make' for glibc-2.12.1 fails even though 'configure' is OK. The failure is: " 1551 /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.4.4/binsh/gcc -B/mnt/sdb8/sergei/AFSWD_debug/install/binutils-2.20.1/ ../sysdeps/i386/i686/multiarch/strcmp.S -c -I../ 1551 include -I/mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/string -I/mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1 -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sy 1551 sv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/lin 1551 ux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/ 1551 inet -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/p 1551 osix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/ 1551 i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps 1551 /ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symb 1551 ols.h -DASSEMBLER -DGAS_SYNTAX -g -Wa,--noexecstack -Wa,-mtune=i686 -o /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/string/strcmp.o -MD -MP -MF /mnt/sd 1551 b8/sergei/AFSWD_debug/build/glibc-2.12.1/string/strcmp.o.dt -MT /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/string/strcmp.o 1552 ../sysdeps/i386/i686/multiarch/strcmp.S: Assembler messages: 1553 ../sysdeps/i386/i686/multiarch/strcmp.S:78: Error: unrecognized symbol type "gnu_indirect_function" 1554 make[2]: *** [/mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/string/strcmp.o] Error 1 1555 make[2]: Leaving directory `/mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1.src/string' 1556 make[1]: *** [string/subdir_lib] Error 2 1557 make[1]: Leaving directory `/mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1.src' 1558 make: *** [all] Error 2 ". With _exactly_ the same settings glibc-2.11.2 builds just fine. Don't bug333 me - it's a clear and obvious regression.
Created attachment 4904 [details] autogenerated script used to run 'configure' for glibc-2.12.1
Created attachment 4905 [details] autogenerated script used to run 'configure' for glibc-2.11.2 which is OK
Created attachment 4906 [details] 'make' screen output of successful glibc-2.11.2 build
Created attachment 4907 [details] 'make' screen output of filing glibc-2.12.1 build
Created attachment 4908 [details] 'make' screen output of successful glibc-2.11.2 build Resending earlier sent make.glibc-2.11.2.log.gz because then by mistake I chose its type as plain text.
For no good reason I've tried to downgrade binutils to binutils-2.19.1 - the same result.
A quick 'grep': " sergei@amdam2:/mnt/sdb5/qemu/install> grep -r gnu_indirect_function /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1 /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/configure.log:checking sysdep dirs... checking for assembler gnu_indirect_function symbol type support... no /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:configure:4361: checking for assembler gnu_indirect_function symbol type support /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:conftest.s:1: Error: unrecognized symbol type "gnu_indirect_function" /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:libc_cv_asm_gnu_indirect_function=no /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/make.log:../sysdeps/i386/i686/multiarch/strcmp.S:78: Error: unrecognized symbol type "gnu_indirect_function" sergei@amdam2:/mnt/sdb5/qemu/install> ". So, 'configure' clearly tells: " checking sysdep dirs... checking for assembler gnu_indirect_function symbol type support... no ", i.e. _no_ gnu_indirect_function support, but 'make' faill with exactly this problem ?! And another quick 'grep': " sergei@amdam2:/mnt/sdb5/qemu/install> grep -r gnu_indirect_function /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.11.2 sergei@amdam2:/mnt/sdb5/qemu/install> echo $? 1 ". So, the problematic 'gnu_indirect_function' entity was not present in glibc-2.11.2 and _is_ present in glibc-2.12.1 and _exactly_ introduction of this entity caused the build failure. Are any excuses going to be used to claim it's not a regression failure ?
Created attachment 4909 [details] 'configure' of glibc-2.12.1 screen output The line explicitly saying 'gnu_indirect_function' is not supported: " 14 checking sysdep dirs... checking for assembler gnu_indirect_function symbol type support... no " - the 'gnu_indirect_function' is the entity causing subsequent 'make' failure.
(In reply to comment #7) > A quick 'grep': > > " > sergei@amdam2:/mnt/sdb5/qemu/install> grep -r gnu_indirect_function > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1 > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/configure.log:checking sysdep > dirs... checking for assembler gnu_indirect_function symbol type support... no > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:configure:4361: > checking for assembler gnu_indirect_function symbol type support > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:conftest.s:1: Error: > unrecognized symbol type "gnu_indirect_function" > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:libc_cv_asm_gnu_indirect_function=no > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/make.log:../sysdeps/i386/i686/multiarch/strcmp.S:78: > Error: unrecognized symbol type "gnu_indirect_function" > sergei@amdam2:/mnt/sdb5/qemu/install> > ". > > So, 'configure' clearly tells: > > " > checking sysdep dirs... checking for assembler gnu_indirect_function symbol type > support... no > ", i.e. _no_ gnu_indirect_function support, but 'make' faill with exactly this > problem ?! > > And another quick 'grep': > > " > sergei@amdam2:/mnt/sdb5/qemu/install> grep -r gnu_indirect_function > /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.11.2 > sergei@amdam2:/mnt/sdb5/qemu/install> echo $? > 1 > ". > > So, the problematic 'gnu_indirect_function' entity was not present in > glibc-2.11.2 and _is_ present in glibc-2.12.1 and _exactly_ introduction of this > entity caused the build failure. > > Are any excuses going to be used to claim it's not a regression failure ? > > > Also, since 'gnu_indirect_function' is a strict substring of 'libc_cv_asm_gnu_indirect_function' and since 'libc_cv_asm_gnu_indirect_function' appears only in " /mnt/sdb8/sergei/AFSWD_debug/build/glibc-2.12.1/config.log:libc_cv_asm_gnu_indirect_function=no " , it means that most likely (unless libc_cv_asm_gnu_indirect_function is synthesized from pieces somewhere else) that the configure check whose result is stored as "libc_cv_asm_gnu_indirect_function=no" is _ignored_.
Of course this is a 333 dup. Don't ever file build problem reports in BZ. This is what mailing lists are for. *** This bug has been marked as a duplicate of 333 ***
(In reply to comment #10) > Of course this is a 333 dup. Don't ever file build problem reports in BZ. This > is what mailing lists are for. > > *** This bug has been marked as a duplicate of 333 ***
(In reply to comment #11) > (In reply to comment #10) > > Of course this is a 333 dup. Don't ever file build problem reports in BZ. This > > is what mailing lists are for. > > > > *** This bug has been marked as a duplicate of 333 *** > > Of course RedHat employs Mr. Ulrich Drepper who is technically incompetent to the extent he doesn't even understand what a regression failure is: http://en.wikipedia.org/wiki/Regression_testing .
(In reply to comment #10) > Of course this is a 333 dup. Don't ever file build problem reports in BZ. This > is what mailing lists are for. > Huh ? I.e. the idea to write quality documentation is completely foreign to you ? And you reject the idea it's the duty of 'configure' to verify presence of prerequisites ? Is this the official RedHat policy ? I mean, users of RedHat products should not count on documentation and look for knowledge at other places ?
(In reply to comment #10) > Of course this is a 333 dup. Don't ever file build problem reports in BZ. This > is what mailing lists are for. > > *** This bug has been marked as a duplicate of 333 *** By the way, Mr. Ulrich Drepper, how about your common sense ? Look at this: http://ftp.gnu.org/gnu/glibc/?C=M;O=D : glibc-2.12.1.tar.bz2 03-Aug-2010 06:06 15M , i.e. look at the _date_. And now look at the date of this bug report. Now, based on your common sense, how many responses can expect in mailing lists taking into account the time passed between the release and my bug report ? Today is only August the 4-th in my timezone, and I am to the East of you, so I found this bug just several hours after the release. And which mailing lists did you mean ?
(In reply to comment #10) > Of course this is a 333 dup. Don't ever file build problem reports in BZ. This > is what mailing lists are for. > > *** This bug has been marked as a duplicate of 333 *** So, I've debugged the issue a little further. The newest assembly I have (and it is supplied through the autogenerated 'configure' wrapper) does support 'gnu_indirect_function': " sergei@amdam2:~/junk> cat conftest.s .type foo,%gnu_indirect_function sergei@amdam2:~/junk> /mnt/sdb8/sergei/AFSWD_debug/install/binutils-2.20.1/binsh/as conftest.s sergei@amdam2:~/junk> echo $? 0 sergei@amdam2:~/junk> ". The 'as' by default installed on my box doesn't: " sergei@amdam2:~/junk> cat conftest.s .type foo,%gnu_indirect_function sergei@amdam2:~/junk> which as /usr/bin/as sergei@amdam2:~/junk> as conftest.s conftest.s: Assembler messages: conftest.s:1: Error: unrecognized symbol type "gnu_indirect_function" sergei@amdam2:~/junk> ". The 'gcc' I am using to build the whole thing was built with installed by default 'as', so it doesn't support 'gnu_indirect_function': " sergei@amdam2:~/junk> cat conftest.s .type foo,%gnu_indirect_function sergei@amdam2:~/junk> /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.4.4/binsh/gcc conftest.s conftest.s: Assembler messages: conftest.s:1: Error: unrecognized symbol type "gnu_indirect_function" sergei@amdam2:~/junk> ". So now the bug is even more obvious - 'configure' should have stopped after detecting that 'gnu_indirect_function' is not supported. So, it looks like RedHat/Mr. Ulrich Drepper QA process simply sucks - nobody apparently bothered to check build mechanism in case of no support for 'gnu_indirect_function'.
Sergei, your tone will not help you in this bugreport. Please calm down before commenting again. Did you read the initial description of bug 333? Nobody says that there's not a bug - what Roland and Ulrich say is: You're on your own and have to investigate it yourself - and that's what you did! http://www.gnu.org/software/libc/resources.html lists the libc-alpha mailing list. A friendly email with your findings is more than welcome. Btw. 2.12.1 was released in July, the tar ball is just newer. *** This bug has been marked as a duplicate of 333 ***
I've rebuilt 'gcc' in a manner that now 'gcc' picks 'as' from binutils-2.20.1, and the build is successful. So, unambiguously and undoubtedly it's a bug in 'configure' - it should have either failed with an appropriate error message or should have taken corrective actions. I am marking the bug as VERIFIED. And had Mr. Ulrich Drepper had personal integrity, he would have immediately admitted it was a bug, and he would have said that he had never checked the scenario in which 'configure' was supposed to fail. As written above, it looks like results of 'configure' check of 'gnu_indirect_function' are simply ignored.
(In reply to comment #16) > Sergei, your tone will not help you in this bugreport. Please calm down before > commenting again. > > Did you read the initial description of bug 333? > > Nobody says that there's not a bug - what Roland and Ulrich say is: You're on > your own and have to investigate it yourself - and that's what you did! > > http://www.gnu.org/software/libc/resources.html lists the libc-alpha mailing > list. A friendly email with your findings is more than welcome. > > Btw. 2.12.1 was released in July, the tar ball is just newer. > > *** This bug has been marked as a duplicate of 333 *** I don't give a damn about bug333. The officially claimed advantage of _open_ source is that users are saved from proprietary vendor lock0in because they can always build from source and modify it if/when necessary. RedHat with its lieutenant Mr. Ulrich Drepper through bug333 perpetuate _open_ source vendor lock-in. Bugs in build mechanism are not even considered. A simple phrase: "yes, it's a bug, make sure your 'as' supports 'gnu_indirect_function' is _not_ said. And if you do not like my tone - I still remember Mr. Ulrich Drepper saying I didn't understand what I was doing and that building 'glibc' is not for everyone.
Created attachment 4914 [details] 'configure' screen output with 'as' supporting 'gnu_indirect_function'
Created attachment 4915 [details] screen output of 'make' of successful build with 'as' supporting 'gnu_indirect_function'