[Bug other/101843] New: Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[Bug other/101843] New: Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

            Bug ID: 101843
           Summary: Build of binutils-2.37 with gcc-11.2.0 fails due to
                    change to libiberty/hashtab.c
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mailboxnotfound at yahoo dot com
  Target Milestone: ---

SUMMARY

   Building binutils along with GCC is a documented method,
   but it fails for gcc-11.2.0 with binutils-2.37 because 
      libiberty/hashtab.c
   differs between gcc-11.2.0 and binutils-2.37

   I have heard that hashtab.c has been updated in GCC master,
   presumably fixing this problem (I have not verified this assertion).

   It would be useful to include a fix in at least GCC 11, 
   and perhaps for other still-supported GCC version.


DETAIL

According to 
   https://gcc.gnu.org/install/download.html 
it is acceptable to build binutils at the same time that one builds GCC.   

However, if one does so by this method:

    cd gcc-11.2.0
    for dir in ../binutils-2.37/*
         if dir does not exist in this gcc tree
               ln -s $dir

then the following directories that already exist in the GCC tree are NOT
replaced by directories from the binutils-2.37 tree

   config/   include/  intl/  libiberty/  zlib/

leading to this failure [white space adjusted] (*)

     libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes
         -Wshadow -I/data1/gcc/build/gcc-11.2.0/binutils/../zlib -g
         -o strip-new objcopy.o is-strip.o rename.o rddbg.o debug.o
         stabs.o rdcoff.o wrstabs.o bucomm.o version.o filemode.o  
         ../bfd/.libs/libbfd.a
-L/data1/gcc/build/Linux-x86_64-gcc-build-11.2.0/zlib
         -lz ../libiberty/libiberty.a -ldl

    objcopy.o: In function `create_symbol_htab':
    /data1/gcc/build/gcc-11.2.0/binutils/objcopy.c:1031: undefined reference to
'htab_eq_string'

The missing symbol, htab_eq_string, is defined in 
../binutils-2.37/libiberty/hashtab.c and ../binutils-2.37/include/hashtab.h

(*) There may be other failures; I did not attempt to do anything resembling 
    make --keep-going


WORKAROUND

    Building gcc-11.2.0 with binutils-2.36 works.


NOT A WORKAROUND 

   Note that this fails:

   $ cd gcc-11.2.0/libiberty/
   $ mv hashtab.c hashtab.c.orig; cp -p ../../binutils-2.37/libiberty/hashtab.c
.
   $ cd ../include
   $ mv hashtab.h hashtab.h.orig; cp -p ../../binutils-2.37/include/hashtab.h .

   The above fails for module gensupport:

   gcc-11.2.0/gcc/gensupport.c:2328:47: error: int htab_eq_string(const void*,
const void*) was declared 'extern' and later 'static'


RECOMMENDATION

   Given that the documentation says that building binutils in your GCC tree
should work, 
   and given the existence of user habits (various google tracks for this
method), 
   it would be useful if at least GCC 11 (and maybe the other still-supported
GCC versions) 
   were fixed such that in-tree builds of binutils-2.37 would work.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |bootstrap
           Keywords|                            |documentation

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The combined tree builds indeed only work for versions where those mentioned
directories are in sync - usually that's binutils master vs. gcc master.  For
release versions your milage may vary and we fail to document working version
pairs.

I'm not sure this is anything but a documentation bug.

For GCC 11 I recommend to use binutils 2.36 instead.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

--- Comment #2 from john henning <mailboxnotfound at yahoo dot com> ---
If this is a doc bug, then two documentation comments
and one other thought.

(1) https://gcc.gnu.org/gcc-11/changes.html  says that certain 
    functionality requires “Binutils version 2.36 or later”. 
    Perhaps that would have been better without the "or later".

(2) Maybe one handy place to document the right version would 
    be in the comments to 
       contrib/download_prerequisites

    For many (most?) systems binutils is not a prerequisite.  

    But sometimes, it is (*) and perhaps the comments to 
    download_prerequisites could include some guidance.  

(3) Or maybe instead of a comment, it could be an option, like 
         download_prerequisites --with-binutils
    in which case it would automatically grab the version that 
    is deemed likely to be useful.

----------

(*) For example, in the days of 
    https://bugzilla.redhat.com/show_bug.cgi?id=1552529 
    Jacob Jelinek commented "You are trying to use f29 gcc 
    with some older binutils (non-f29).  Don't do that."

    Right now, I am building on several systems; I 
    think only one of them will actually end up requiring it.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
You can certainly use gcc 11 and binutils 2.37 together, just not building them
in a single source tree.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Combined source builds are not for released sources unless you are going to
change/fix them yourself.  They are useful for building the trunk sources only
really.

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

--- Comment #5 from john henning <mailboxnotfound at yahoo dot com> ---
Andrew suggests: Combined source builds are not for released sources
Respectfully, I suggest that the documentation disagrees.  
Please see the binutils paragraph of the documentation of the released version
at
      https://gcc.gnu.org/install/download.html 

Plus there are google tracks and user habits doing so.

It would be useful if the gcc-n.n.n documentation specifically suggested which
binutils-n.nn is likely to be useful.

Or, it would be useful if there were a switch something like:

      download_prerequisites --with-binutils

[Bug bootstrap/101843] Build of binutils-2.37 with gcc-11.2.0 fails due to change to libiberty/hashtab.c

[mailboxnotfound at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843

--- Comment #6 from john henning <mailboxnotfound at yahoo dot com> ---
Let's simplify.

Per Richard's comment #1, there won't be a code fix.  OK.  
As to a doc fix, Richard wrote: 

  "For release versions your milage may vary and we fail to document working
version pairs"

YES - it would be nice if working pairs were documented in a list somewhere.
BUT - it might also be difficult to keep such a list updated.

So let's simplify.  How about if 
      https://gcc.gnu.org/install/download.html 
were to just include the generic advice that if you want to build them
together, then you should pick versions that were developed at about the same
timeframe.

(Yes, this is obvious advice once you understand that they have common
subdirectories, such as libiberty/.  But it was not obvious to at least one
user; and if that advice had been present, the user might have avoided a side
track.)

I've started to bat around possible specific language and perhaps will propose
a specific patch along these lines.