Fix binutils/gold breakage [XCC]

[Dan Cross]

The following changes since commit 2a9b3cdc47dbde55f9d125fde3e11832ca4c0b91:

  Avoid double declarations, integer overflow, and use branch hints (2015-10-30 16:02:29 -0400)

are available in the git repository at:

  g...@github.com:dancrossnyc/akaros.git binutils

for you to fetch changes up to d5b528993a93a4a135f4b5edb2bcb29412171ef3:

  Fix binutils/gold breakage [XCC] (2015-11-02 15:19:59 -0500)

----------------------------------------------------------------

Dan Cross (1):

      Fix binutils/gold breakage [XCC]

 tools/compilers/gcc-glibc/binutils-2.24-akaros.patch | 18 ++++++++++++++++++

 1 file changed, 18 insertions(+)

diff --git a/tools/compilers/gcc-glibc/binutils-2.24-akaros.patch b/tools/compilers/gcc-glibc/binutils-2.24-akaros.patch

index 8ccc83b..a284c5c 100644

--- a/tools/compilers/gcc-glibc/binutils-2.24-akaros.patch

+++ b/tools/compilers/gcc-glibc/binutils-2.24-akaros.patch

@@ -69,6 +69,24 @@ diff -ur binutils-2.24/gas/configure.tgt binutils-2.24-ros/gas/configure.tgt

    i386-*-kaos*) fmt=elf ;;

    i386-*-bsd*) fmt=aout em=386bsd ;;

    i386-*-nacl*) fmt=elf em=nacl

+diff -ur binutils-2.24/gold/binary.cc binutils-2.24-ros/gold/binary.cc

+--- binutils-2.24-ros/gold/binary.cc 2015-11-02 15:17:29.049801929 -0500

++++ binutils-2.24-ros/gold/binary.cc 2015-11-02 15:17:38.246051136 -0500

+@@ -24,13 +24,13 @@

+

+ #include <cerrno>

+ #include <cstring>

+-#include "safe-ctype.h"

+

+ #include "elfcpp.h"

+ #include "stringpool.h"

+ #include "fileread.h"

+ #include "output.h"

+ #include "binary.h"

++#include "safe-ctype.h"

+

+ // Support for reading binary files as input.  These become blobs in

+ // the final output.  These files are treated as though they have a

 diff -ur binutils-2.24/ld/configure.tgt binutils-2.24-ros/ld/configure.tgt

 --- binutils-2.24/ld/configure.tgt 2013-11-26 06:37:33.000000000 -0500

 +++ binutils-2.24-ros/ld/configure.tgt 2015-03-13 19:04:52.888987865 -0400

[Kevin Klues]

Really, just moving the #include "safe-ctype.h" fixes it. Is this
something from our original patch that included this in the first
place like this? Not judging, just curious.

> --
> You received this message because you are subscribed to the Google Groups
> "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akaros+un...@googlegroups.com.
> To post to this group, send email to aka...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
~Kevin

[Dan Cross]

Nope; this comes directly from upstream.

The issue is that the standard defines these as functions (Sec 7.4 for C11; Secs 21.8, 22.2 and 22.3.3.1 for C++14), but 'safe-ctype.h' redefine them as macros; those macros can conflict with functions that have those same names (e.g., that come from C++ headers).

Moving 'safe-ctype.h' to the end of the #include list means that all of those system headers are processed by the preprocessor/compiler before those macros are #define'd by 'safe-ctype.h', so they won't conflict with anything.

My suspicion is that most systems just don't have these conflicts by happenstance. In general, one shouldn't rely on the notion that symbols defined by the standard to be functions may actually be macros (though historically and generally in practice this is true).

        - Dan C.

[Barret Rhoden]

Thanks, merged to staging at b3dc4ab6cc78..6237090137f8 (from, to]

You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/b3dc4ab6cc78...6237090137f8