Bug 12478 - discrepancy between 'ld.1' file and 'configure'
Summary: discrepancy between 'ld.1' file and 'configure'
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.21
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-10 18:12 UTC by Sergei Steshenko
Modified: 2011-02-13 23:39 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Steshenko 2011-02-10 18:12:33 UTC
As I'm reading

man /mnt/sdb8/sergei/AFSWD_debug/install/binutils-2.21/share/man/man1/ld.1

, I see among other things:

    859        --sysroot=directory
    860            Use directory as the location of the sysroot, overriding the configure-time default.  This option is only supported by linkers that were configured
    861            using --with-sysroot.

, i.e. the manpage effectively claims there is '--with-sysroot' 'configure' option.

OTOH, the following is true:

"
sergei@amdam2:~> /mnt/sdb8/sergei/AFSWD_debug/build/binutils-2.21/configure --help | grep sysroot
  --with-build-sysroot=SYSROOT
                          use sysroot as the system root during the build
sergei@amdam2:~> 
",

i.e. 'configure' provides '--with-build-sysroot' and _not_ '--with-sysroot' option.

So, I do not know the meaning of 'configure' option and I don't know how to achieve the advertised in 'ld.1' file functionality WRT sysroot.
Comment 1 Alan Modra 2011-02-11 04:30:22 UTC
You are looking at the wrong "configure".  Look instead at ld/configure.
Comment 2 Sergei Steshenko 2011-02-11 10:25:27 UTC
(In reply to comment #1)
> You are looking at the wrong "configure".  Look instead at ld/configure.

Which lines of the top level 'configure' built-in help-message and/or of README file tell me to do this ?

Which lines of the top level 'configure' built-in help-message and/or of README file tell me that top level 'configure' at all accepts command line switches not mentioned in the built-in help message and passes them to lower level 'configure' scripts ? Or it's not the case ?
Comment 3 Andreas Schwab 2011-02-11 10:40:13 UTC
./configure --help=recursive
Comment 4 Sergei Steshenko 2011-02-11 11:16:07 UTC
(In reply to comment #3)
> ./configure --help=recursive

Which part of

./configure --help=recursive

output tells that top level 'configure' options are passed to lower level 'configure' scripts ?

Which part of

./configure --help=recursive

output tells that top level 'configure' accepts options that are not mentioned in its built-in help message and passes them to lower level 'configure' scripts ?
Comment 5 Andreas Schwab 2011-02-11 11:23:17 UTC
It lists all options that are accepted.
Comment 6 Sergei Steshenko 2011-02-11 13:47:20 UTC
(In reply to comment #5)
> It lists all options that are accepted.

Which/what "it" ?

Again, I do not see in top level 'configure' mentioning that _all_ options are accepted.

Typically, if a script/program lists available command line options, the one which are not listed are not accepted.

The only thing which is intuitively clear to me is that top level 'configure' calls other 'configure' scripts (in subdirectories), but nothing is clear WRT acceptability of options.
Comment 7 Andreas Schwab 2011-02-11 14:34:25 UTC
All accepted options are listed.
Comment 8 Sergei Steshenko 2011-02-11 21:37:24 UTC
No, they are not. That is, from the listing one can correctly guess that _other_ 'configure' scripts are called, but nothing says that top level 'configure' options listed in its built-in help message are passed "as is" to lower level configure.

As I wrote, _normal_ behavior is to check option, not turn a blind eye on them.
Comment 9 Andreas Schwab 2011-02-11 21:50:01 UTC
./configure --help=recursive lists all accepted options.
Comment 10 Sergei Steshenko 2011-02-13 22:50:33 UTC
(In reply to comment #9)
> ./configure --help=recursive lists all accepted options.

How about addressing my statement that normal programs check validity of their options ?

How about rereading, say, 'gcc' documentation, for example, gcc-4.4.5, the gcc.pdf, file, page 130:

"
-Xassembler option
          Pass option as an option to the assembler. You can use this to supply system-
          specific assembler options which GCC does not know how to recognize.
".

I.e. in 'gcc' case it _clearly_ written ("You can use this to supply system-
          specific assembler options which GCC does not know how to recognize") that 'gcc' does _not_ check validity of options passed to another program (assembler in this case).

How about being consistent ? I mean' 'gcc' is also supported by 'sourceware'.
Comment 11 Alan Modra 2011-02-13 23:39:17 UTC
This bug has been closed five times already as invalid.  What do you think you are achieving by reopening it?  Do you think that annoying binutils maintainers will help you in any way?