Bug 11875 - 'make' fails even though 'configure' is OK
Summary: 'make' fails even though 'configure' is OK
Status: VERIFIED DUPLICATE of bug 333
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.12
: P2 critical
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-04 04:22 UTC by Sergei Steshenko
Modified: 2014-06-30 17:25 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
autogenerated script used to run 'configure' for glibc-2.12.1 (848 bytes, text/plain)
2010-08-04 04:24 UTC, Sergei Steshenko
Details
autogenerated script used to run 'configure' for glibc-2.11.2 which is OK (850 bytes, text/plain)
2010-08-04 04:26 UTC, Sergei Steshenko
Details
'make' screen output of successful glibc-2.11.2 build (217.90 KB, text/plain)
2010-08-04 04:35 UTC, Sergei Steshenko
Details
'make' screen output of filing glibc-2.12.1 build (38.86 KB, application/x-gzip)
2010-08-04 04:36 UTC, Sergei Steshenko
Details
'make' screen output of successful glibc-2.11.2 build (217.90 KB, application/x-gzip)
2010-08-04 04:38 UTC, Sergei Steshenko
Details
'configure' of glibc-2.12.1 screen output (1.88 KB, text/x-log)
2010-08-04 06:07 UTC, Sergei Steshenko
Details
'configure' screen output with 'as' supporting 'gnu_indirect_function' (1.89 KB, text/x-log)
2010-08-05 18:52 UTC, Sergei Steshenko
Details
screen output of 'make' of successful build with 'as' supporting 'gnu_indirect_function' (219.24 KB, application/x-gzip)
2010-08-05 18:55 UTC, Sergei Steshenko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Steshenko 2010-08-04 04:22:04 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.
Comment 1 Sergei Steshenko 2010-08-04 04:24:05 UTC
Created attachment 4904 [details]
autogenerated script used to run 'configure' for glibc-2.12.1
Comment 2 Sergei Steshenko 2010-08-04 04:26:12 UTC
Created attachment 4905 [details]
autogenerated script used to run 'configure' for glibc-2.11.2 which is OK
Comment 3 Sergei Steshenko 2010-08-04 04:35:30 UTC
Created attachment 4906 [details]
'make' screen output of successful glibc-2.11.2 build
Comment 4 Sergei Steshenko 2010-08-04 04:36:33 UTC
Created attachment 4907 [details]
'make' screen output of filing glibc-2.12.1 build
Comment 5 Sergei Steshenko 2010-08-04 04:38:59 UTC
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.
Comment 6 Sergei Steshenko 2010-08-04 05:24:01 UTC
For no good reason I've tried to downgrade binutils to binutils-2.19.1 - the
same result.
Comment 7 Sergei Steshenko 2010-08-04 05:47:18 UTC
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 ?


Comment 8 Sergei Steshenko 2010-08-04 06:07:49 UTC
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.
Comment 9 Sergei Steshenko 2010-08-04 07:11:23 UTC
(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_.
Comment 10 Ulrich Drepper 2010-08-04 07:12:34 UTC
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 ***
Comment 11 Sergei Steshenko 2010-08-04 07:50:24 UTC
(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 ***

Comment 12 Sergei Steshenko 2010-08-04 07:53:10 UTC
(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
.
Comment 13 Sergei Steshenko 2010-08-04 09:57:21 UTC
(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 ?
Comment 14 Sergei Steshenko 2010-08-04 11:59:59 UTC
(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 ?

Comment 15 Sergei Steshenko 2010-08-04 15:31:12 UTC
(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'.

Comment 16 Andreas Jaeger 2010-08-04 19:54:43 UTC
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 ***
Comment 17 Sergei Steshenko 2010-08-05 18:40:13 UTC
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.
Comment 18 Sergei Steshenko 2010-08-05 18:48:10 UTC
(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.



Comment 19 Sergei Steshenko 2010-08-05 18:52:26 UTC
Created attachment 4914 [details]
'configure' screen output with 'as' supporting 'gnu_indirect_function'
Comment 20 Sergei Steshenko 2010-08-05 18:55:53 UTC
Created attachment 4915 [details]
screen output of 'make' of successful build with 'as' supporting 'gnu_indirect_function'