Revert "binutils: multiple version up."

This reverts commit 9497c734.
This reverts commit c55337f2.

This causes other build failures on some environments.
Turns out, this was not even enough to get gcc to fully build on my
environment, so more fixes are needed.

component/binutils/buildout.cfg

@@ -42,8 +42,8 @@ environment =
 [binutils]
 recipe = slapos.recipe.cmmi
 shared = true
-url = http://ftp.gnu.org/gnu/binutils/binutils-2.41.tar.bz2
-md5sum = b572fd7ea427a8f5a3be58d50bd7ea7e
+url = http://ftp.gnu.org/gnu/binutils/binutils-2.32.tar.bz2
+md5sum = 64f8ea283e571200f8b2b7f66fe8a0d6
 configure-options =
   --disable-bootstrap
   --with-mpc=${mpc:location}

[Thomas Gambier]

For your information @vpelletier I'm upgrading binutils in !1404 (merged)

I hope, I can merge this this week...

[Vincent Pelletier]

@tomo Thank you very much. I have not found time to work further on investigating the failure reported by @xavier_thompson , nor on the build failure further in gcc build to which I am alluding in the present commit message.

The second build failure I had (which I do not have anymore, I reverted my software release state to its previous state and so do not have the gcc build dir anymore) was (system) gcc detecting a redefinition of an enum and of a struct in linux headers. The redefinition was caused by some part of gcc (the one being built) including both:

• a header apparently generated by some tool within the gcc source based on system's /usr/include/x86_64-linux-gnu/sys/mount.h
• /usr/include/linux/mount.h, which defines compatible enums and struct, but still gcc rejects them

From what I could see, the former used to have #ifdefs around the structs & enums which used to avoid the duplicate definition, but they do not anymore.

I could not identify why gcc (the one being build) felt the need to alter and have a copy of /usr/include/x86_64-linux-gnu/sys/mount.h, and especially I could not find which filter rule got applied. IIRC the diff was the one-liner:

- # if __has_include ("linux/mount.h")
+ # if __has_include ("__linux__/mount.h")

which did not match any obvious rule in the header patching tool.

So, overall, gcc fails to build because of a dynamically-generated file based on some system file input and rules I cannot find, and then proceeds to import another system file which does the same thing, which then makes gcc angry.

I have no idea which thing we need to change in order to resolve this issue: Identify and patch the rule ? Somehow prevent the system file from being patched ? Enable some (system) gcc option which makes it tolerate redefined-but-compatible enums and structs ?

One level higher, I believe we build this gcc only to build kumofs (I have not checked). Maybe it would be easier to patch kumofs code so it builds on modern gcc ? Or maybe we should finally move on to another memcached implementation, and ditching long-unmaintained kumofs. For example, back when memcached was popular I remember mariadb (or mysql ?) announcing a key-value store served by the same process and independent from the SQL side. If this can be used and removes a dependency it could be worth a look. I cannot find any trace of it now (because "key", "value" and "store" are hardly distinctive words in a database context...). I do not even remember if the protocol was memcache-compatible, just that it was not SQL.