Some more Gentoo activity

Even though I’m spending most of my time working on paid jobs, I’ve returned active in Gentoo, although I’m mostly doing testbuilding for --as-needed lately. Yamato, with its 8-core horsepower, is still building tree, I left it before going to my bedroom to relax a bit that it was finishing the game-arcade catgory. I’ve been committing the most trivial stuff (missing deps, broken patches, and stuff like that), and opening bugs for the rest. The result is that the “My Bugs” search on Gentoo’s bugzilla reports over one thousand bugs.

Also, tonight I spent the night fixing the patches currently in tree so that absolute paths are replaced by relative ones, since epatch now fails if you try to apply a patch that has absolute paths (because when they don’t add up you’d be introducing subtle bugs that might apply to users but not to you). The result has been an almost tree-wide commit spree that sanitised the patches so that they won’t fail to apply for users. It was a long boring and manual job but it was completed, and of that I’m happy.

But it’s not all well. as Mike (vapier) pointed out, trying to just report all failures related to -Wl,--no-undefined is going to produce a huge amount of bugspam for false positives. In cases like zsh plugins, you really can’t do much more than passing -Wl,--undefined to disable the previous option. Which makes -Wl,--no-undefined too much of an hassle to be usable in the tree. On the other hand it’s stil an useful flag to ask upstream to adopt for their ow builds, so that there are no undefined symbols. I think I’ll doublecheck all the software I contribute to to add this flag (as a special exception, this flag needs to be used only on Linux, since on other systems it might well be a problem, for instance on BeOS dynamic patching is more than likely to cause problems, and on FreeBSD the pthread functions are not usually linked in libraries).

This, and the largefile problem I wrote about brings me to wonder what we can do to improve even further the symbiosis between Gentoo and the various upstream. I’m sure there are tons of patches in the tree that hasn’t been sent, and I’m afraid that --as-needed patching will cause even more to be introduced. I wonder if there could be volunteers that spend time checking package per package the patches so that they are sent upstream, checking the Unmaintained Free Software wiki so that if a package is not maintained by upstream anymore there are references to our patches if somebody wants to pick it up.

I could be doing this myself, but it takes time, and lately I haven’t had much; I could try to push myself further but I currently don’t see much of the point since I sincerely have had very little feedback from users lately, beside the small stable group of users who I esteem very much and who’s always around when I need help. Even just a kudo on ohloh would be nice to know my work is appreciated, you know. Anyway if you’re interested in helping with submitting stuff upstream, please try to contact me, so I can see to write down upstream references in the patches that we have in tree.

Also, since I started working “full time” on --as-needed issues, I had to leave behind some things like closing some sudo bugs and some PAM issues, like the one with OpenSSH and double lastlogin handling. I hope to resume those as soon as I free some of my time from paid jobs (hopefully having some money spare to pay for Yamato, which still ain’t completely paid for, and which by this pace is going to need new disks soon enough, considering the amount of space that the distfiles archive, as well as the built chroot, take. I actually hope that Iomega will send the replacement for my UltraMax soon since I wanted to move music and video on that external drive to free up a few hundreds gigabytes from the internal drives.

Once the build is completed, I’ll also have to spend time to optimise my ruby-elf tools to identify symbol collisions. I haven’t ran the tools in almost an year, and I’m sure that with all the stuff I mergd in that chroot, I’m going to have more interesting results than the one I had before. I already started looking for internal libraries, although just on account of exported symbols, which is, as you probably know, a very bland way to identify them. A much more useful way to identify those is by looking at the DWARF debug data in the files, with utilities like pfunct from the dwarves package. I haven’t built the chroot with debug information though, since otherwise it would have required much more on-disk space, and the system is already a few tens gigabytes, without counting portage, distfiles, packages, logs or build directories.

In the mean time even with the very bland search, I found already a few packags that do bundle zlib, one of which bundles an old version of zlib (1.2.1) which as far as I remember is vulnerable to some security issues. Once again having followed policy would have avoided the problem altogether, just like SDL bundling its own versions of Xorg libraries which can now make xorg-server crash when an SDL application is executed. Isn’t it pure fun?

At any rate, for tonight I’m off, I did quite a lot already, it’s 4.30 am and I’m still not sleepy, something is not feeling right.

Building the whole portage

Since my blog post about forced --as-needed yesterday, I started building the whole portage in a chroot to see how many packages break with the forced --as-needed at build time. While build-time failure are not the only problem here (for stuff like Python, Perl and Ruby packages, the failure may well be at runtime), build-time failure are probably the most common problem with --as-needed; if we also used --no-undefined, like Robert Wohlrab is trying (maybe a little too enthusiastically), most of the failures would be at build time by the way.

As usual, testing one case also adds tests for other side cases, this time I’ve added further checks to tell me if packages install files in /usr/man, /usr/info, /usr/locale, /usr/doc, /usr/X11R6, …and filed quite a few bugs about that already. But even without counting these problems, the run started telling me some interesting thing that I might add to the --as-needed fixing guide when I get back to work on it (maybe even this very evening).

I already knew that most of the failures I’d be receiving would be related to packages that lack a proper buildsystem and thus ignored LDFLAGS up to now (included --as-needed), but there are a few notes that really gets interested here: custom ./configure scripts seem to almost always ignore LDFLAGS and yet fail to properly link packages; a few glib-based packages fail to link to libgthread the main executable, failing to find g_thread_init(); and a lot of packages link the wrong OpenSSL library (they link libssl when they should link libcrypto).

This last note, about OpenSSL libraries, is also a very nice and useful example to show how --as-needed helps users in two main ways. Let’s go over a scenario where a package links in libssl instead of libcrypto (since libssl requires libcrypto, the symbols are satisfied, if the link is done without --as-needed).

First point: ABI changes: if libssl changed its ABI (happens sometimes, you know…), but libcrypto kept the same, the program would require an useless rebuild: it’s not affected by libssl ABI, but by libcrypto’s.

Second point, maybe even more useful at runtime: when executing the program, the libraries in NEEDED are loaded, recursively. While libssl is not too big, it would still require loading one further library that is unneeded to the program since libcrypto is the one that is actually needed. I sincerely don’t know if libssl has any constructor functions, but when this extra load happens with libraries that have many more dependencies, or constructor functions, it’s going to be a quite huge hit for no good reason.

At any rate, I wish to thank again all the people who contributed to pay for Yamato, as you can see the horsepower in it is being put to good use (although I’m still just at app-portage); and just so I don’t have to stress it to do the same work over and over again, I can tell you that some of the checks I add to my chroots for building are being added to portage, thanks to Zac, who’s always blazing fast to add deeper QA and repoman warnings, so that further mistakes don’t creep into the new code.. one hopes, at least.

Oh and before people start expecting cmake to be perfect with --as-needed, since no package using it has been reported as failing with --as-needed … well the truth is that I can’t build any package using cmake in that chroot since it fails to build because of xmlrpc-c. And don’t get me started again on why a build system has to use XML-RPC without a chance for the user to tell “not even in your dreams”.

Problems and mitigation strategies for –as-needed

Doug and Luca tonight asked me to comment about the --as-needed by default bug. As you can read there, my assessment is that the time is ready to bring on a new stage of --as-needed testing through use of forced --as-needed on specs files. If you wish to help testing with this (and I can tell you I’m working on testing this massively), you can do it by creating your own asneeded specs.

Note, Warning, End of the World Caution!

This is not a procedure for the generic users, this is for power users, who don’t mind screwing up their system even beyond repair! But it would help me (and the rest of Gentoo) testing.

First of all you have to create your own specs file, so issue this command:

# export SPECSFILE=$(dirname "$(gcc -print-libgcc-file-name)")/asneeded.specs
# export CURRPROFILE=/etc/env.d/gcc/$(gcc-config -c)
# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr: --as-needed:' > "$SPECSFILE"
# sed "${CURRPROFILE}" -e '1iGCC_SPECS='$SPECSFILE > "${CURRPROFILE}-asneeded"
# gcc-config "$(basename "${CURRPROFILE}")-asneeded"
# source /etc/profile

This will create the specs file we’re going to use, it just adds —as-needed for any linking command that is not static, then it would create a new configuration file for gcc-config pointing to that file. After this, —as-needed will be forced on. Now go rebuild your system and file bugs about the problems.

A package known to break with this is xmlrpc-c, which in turn makes cmake fail; as some people lack common sense (like adding a way to not have xmlrpc-c as a dependency because you might not want your cmake to ever submit the results of tests), this can get nasty for KDE users. But maybe, just maybe, someone can look into fixing the package at this point.

But xmlrpc-c does require some reflection on how to handle --as-needed in these cases: the problem is that the error is in one package (xmlrpc-c) and the failure in another (cmake) which makes it difficult to asses whether --as-needed break something; you might have a broken package, but nothing depending on it, and never notice. And a maintainer might not notice that his package is broken because other maintainers will get the bugs first (until they get redirected properly). Indeed it’s sub-optimal.

Interestingly enough, Mandriva actually started working on trying to resolve this problem radically, they inject -Wl,--no-undefined in their build procedures so that if a library is lacking symbols, the build dies sooner rather than later. This is fine up to a certain point, because there are times when a library does have undefined symbols, for instance if it has a recursive dependency over another library (which is the case of PulseAudio’s libpulse and libpulsecore, which I discussed with Lennart some time ago). Of course you can work this around by adding a further -Wl,--undefined that then tells ld to discard the former, but it requires more work, and more coordination with upstream.

Indeed, coordination with upstream is a crucial point here, since having to maintain --as-needed fixes in Gentoo is going to be cumbersome in the future, and even more if we start to follow Mandriva’s steps (thankfully, Mandriva is submitting the issues upstream so that they get fixed). But I admit I also haven’t been entirely straight on that; I pushed just today a series of patches to ALSA packages, one of which, to alsa-tools, was for --as-needed support (the copy we have in Portage also just works around the bug rather than fixing it). Maybe we need people that starts checking the tree for patches that haven’t been pushed upstream and tries to push them (with proper credits of course).

Another thing that we have to consider is that many times we have upstream that provide broken Makefiles, and while sending the fix upstream is still possible, fixing it in the ebuild takes more time than it is worth; this is why I want to refine and submit for approval my simple build eclass idea, that at least works as a mitigation strategy.

Delegating

No I’m not working on C# again, although I admit i have Mono installed. Actually to be honest I’m not working on anything at the moment.

I have scheduled a visit in Verona next Tuesday, then they’ll probably tell me when I’ll have surgery, and which kind of surgery. Up to then I’m not sure how to organise myself with jobs and other things so I’ll probably keep a very low profile.

So, to make sure I don’t end up leaving packages unmaintained and bugs unseen, I’m trying now to delegate as much as I can of my responsibilities to other developers. Hopefully this way there won’t be anything left untouched while I’m convalescent.

The only things I’ll be working on this week, and even those only briefly, are short documentation updates, and maybe, but just maybe, version bumps. I already updated the --as-needed fixing guide trying to make it a bit more clear what to do with some errors, and how to properly filter the flag, and when to actually filter it. I’ll probably write something more about that, and then start seeing if I can write something about autotools update problems.

I’m doing this because multiple people (both devs and non) contacted me while I was in the hospital asking how to fix stuff, for --as-needed, new libtool, new autoconf, and so on. As I cannot really answer them while I’m in the hospital, I’d rather see to write a proper guide before I enter again, and then leave that to them as a reference.

I really can’t afford another pancreatitis, so I’ll have to reduce my stress levels a lot. Help with stuff I’ve been working on is very very welcome. So if you wish to spare some time and help me with, for instance, identifying packages that need to be fixed to work with OpenPAM, so that Seraphim’s work could be actually made good use of after it’s done.

Now I’ll cut this entry short, as I want to take care of other things today, like being able to play a bit (I haven’t played seriously in weeks!), plus I have to download from the camera some more photos I made this morning.

Again, donations to me, gifts, but even more importantly, day after day, to the research on pancreatic diseases are welcome.

Some more useful information about –as-needed

While Ciaran continues spreading the word that --as-needed is broken because it disallows some techniques that, in my opinion, are crazy enough by themselves, and wouldn’t work with Sun’s compiler or with some executable formats like Microsoft’s own PE, there are some more information about --as-needed that I’d like people to know about.

In general, with the exception of some rare, and as I said crazy, to me, designs, --as-needed is almost always fixable. The speed of the fix is usually inversely proportional to the decency of the build system.

On a standard autotools-based build system, with some exception about cyclic dependencies of modules, the problem is usually solvable in a few minutes. Usually, it’s due to libraries passed through _LDFLAGS variables instead of _LDADD or _LIBADD (depending whether the target is an executable or a library). Sometimes its caused by mistakes in the configure script though.

In particular, if you’re testing for the presence of a library, you want to pass it through the LIBS variable, rather than LDFLAGS (and remember I consider AC_CHECK_LIB harmful). For those who disagree because some software passes flags like -L through their config scripts, well, those are flags that fit perfectly in LIBS as they are libary lookup flags!

Unfortunately there are very broken build systems, like the one of xmlwrapp, that creates shared objects in ELF with no dependency, without linking any other library together and thus expecting all its users to know the list of libraries it links against (it reports a huge list of libraries through pkg-config).

In these cases, fixing the issue might require quite a lot of work. Doesn’t mean it’s impossible though, of course, just annoying, long, and boring.

To avoid introducing more issues like these, in agreement with Mike, I’ve introduced a new warning in append-ldflags, if you try to pass the -l option to link against a library, it will tell you not to do that. That’s a mistake that will cause --as-needed to fail.

Whatever I’m saying here, anyway, makes no difference on whether the designs that clash with --as-needed are sane or not. Passing libraries through LDFLAGS is a mistake, --as-needed or not, it only happens to break stuff when --as-needed is used. So let’s not put our heads under the sand and filter --as-needed directly, let’s try to fix the issue, okay?

And of course to finish, if you are unable to fix an --as-needed issue, whether you don’t have time, will, or simply think to lack the skill to fix it, let me know and I’ll do everything I can to fix the issue myself, just please don’t filter the flag up without leaving a bug open, okay? If the package is important and you want users to be able to build anyway, well, okay filter out the flag, but leave a bug open so I know it has to be fixed.

Developers seem to feel like having bugs open is a failure, instead it’s just a way to track things down. If an issue is just partly worked around, or is fixed in the wrong way, leave the bug open, maybe put it to assigned, so that you can filter it out, use the status whiteboard, whatever you want, but don’t write the bug off as FIXED, if it is not.

I consider AC_CHECK_LIB harmful

You know I always stress the point that it’s not autoconf (and automake) to be bad per-se, but rather the fact that it’s poorly documented and most people get the worst examples on how to do stuff.

One thing that I find totally misdesigned in autoconf though is the AC_CHECK_LIB macro. This macro is supposedly designed to look for certain functions in a library, to make sure that it’s linked upon if needed. The most simple case for this is using

AC_CHECK_LIB([dl], [dlopen])

to gather if the dlopen() function is in libdl or would be available directly from the C library. (Actually you usually use something more complex than this, but that’s another story).

What is the problem of this macro? Well, the problem comes when you check non-generic functions, because it has a side effect: if the function is found on the library, it is added to the LIBS variable, that is appended to every link line, causing the library to be linked in every target. This is fine when you only have one target, but it’s nasty in every other case.

This is one of the main cause of extra libraries being linked in on other libraries and executables, which are worked around with --as-needed (at least ELF side, as --as-needed does not help with libtool archives at all). It should really be avoided.

The easy way to avoid this is to reset the LIBS variable after AC_CHECK_LIB to the value it had before, it also helps if you set a new variable with the library you just detected, to use just where needed. A better way to handle this is to push on using pkg-config, which might not be the solution to all problems, but makes this problem quite easier to handle.

I know most people doing this mistake won’t be reading this, but at least I have it documented somewhere so that I can just point people at this post without repeating the reasoning. And yes, it’s problem like these that makes neon link against pam for no good reason.

Games

Strange title for me, uh? I usually don’t play too much, but during August, having been alone most of the time and without anything to do, I’ve ended up actually playing for a while.

What I played? Well, mostly puzzle games, like FloboPuyo and Angry Drunken Dwarves (Mr. Bones: thanks for telling me about the latter, it’s really good to pass the time :)), but I also finally finished SuperTux! And that is strange to me as I’m rarely able to finish a game myself. Most of the time I end up giving up in the middle, if I reach the middle.

When I was a child, and I used my sister’s 286 to play in MS-Dos 5 or 6, it was my sister who actually finished the games, I simply tried and tried and tried and failed, at least for the various action and similar games.

The only kind of games I was actually able to complete alone were graphic adventures, like Monkey Island 2, Indiana Jones and the Last Crusade and so on. Although I wouldn’t have been able to complete Colonel’s Bequest without my sister and my brother in law, at the time I wasn’t that good in English either (I suppose it’s one of the things that made me want to learn it). A few exceptions hits: I was able to complete Street Fighter Alpha 3 emulated with WinKawaks, and I reached the last level of Throne of Darkness (that game is awesome, too bad I don’t have time to play with it anymore :( I lost the savegame in an HDD crash, that’s why I never completed it). I cannot remember any other game I played till the end.

Now, to play all those games with the dual screen was a mess, because I wanted full screen (even if it has the black borders anyway), and that wasn’t possible with SDL, even built with xinerama support and after setting SDL_VIDEO_FULLSCREEN_HEAD=0, but it worked with SDL_VIDEO_FULLSCREEN_HEAD=1. I ended up looking at the source code of SDL and prepared a patch, that’s now in “bug #145917”, so that the value 0 for the head variable works as intended. Sometimes even playing make you do something good, don’t you think?

Anyway, I think I’ll try to leave some game installed in this box from time to time, so that I’ll have something to play with in the unlucky case I get disconnected again.

On an off-topic note, yesterday I tried cleaning up a few bugs from xine tracker, but there is really a lot of stuff that needs to be fixed there, and most of it, I have no clue about :( I can understand audio codecs, but video is out of my reach, with the time I have. PulseAudio in Gentoo, instead, is boosted once again, as 0.9.5-r1 revision has a fixed esdcompat script and returns to work on FreeBSD. Thanks Lennart for the quick merge of the patches, now PulseAudio SVN builds and works as a charm on FreeBSD (also vanilla of course); to be able to build SVN version you also need libatomic_ops, now in portage.

For other Gentoo things, thanks to Jokey geoip-1.4.0 is in portage, with an asneeded patch to build fine for the ones still using —as-needed (like me), that I need to add the new TorK (because I don’t want it to use the internal copy). I also fixed the dependency trees for Gentoo/FreeBSD, because while I was away a couple of packages dropped the keywords, messing it up badly :(

I think I should really try to get a fixing spree in the —as-needed tracker bug, but I really don’t have much time right now, as I’m also looking for replacing my old job (sigh). But I’ll try for sure, if not today in the next days, to improve this situation along with xine-lib bugs. Well, I might get more time if I end up without a job :P

And thanks to deathwing00, the KDE Project page is now undergoing a face lifting :) I’ll try to draft up some documentation on kde eclasses too, so that next time my telcos disconnet my cable, at least someone can take care of my packages. I’ll also write something about PulseAudio most likely.

Why can’t we use –as-needed on Gentoo/FreeBSD?

Here it is again one of my informative blog posts, for future memento and for asking comments about this.

Yesterday I was talking yesterday with drizzt about --as-needed having trouble on Gentoo/FreeBSD, I tried, and I’ve seen that on 2.17 it worked fine. So I thought with myself “Why don’t enable it?” and so I did..

The first package I merged was a KDE theme, and it didn’t find Qt. I tried another and again the same problem, so I decided looking at the problem, and here it is the description.

The -pthread flag used to link against libpthread on Linux and FreeBSD, has a particular meaning on FreeBSD. Basically, if the result is an executable libpthread.so is added to the NEEDED lines, but when generating a shared object, that is not added.

One might think of a GCC bug, either the Gentoo one, or in general. But actually, there’s a reason for that. There are more than one pthread implementation in FreeBSD: one can use -lthr to use libthr threads rather than pthread. When using -pthread option, no library is linked when creating a shared object, so that when one create a final executable, that might come out of a totally another package, the threading library can be chosen freely. Unfortunately, this entirely breaks when using --as-needed.

So, for now, I have to say that --as-needed is not supposed to work on Gentoo/FreeBSD, until I can find a way to work this around. The easy part would be to use -Wl,--no-as-needed -pthread -Wl,--as-needed as PTHREAD_LIBS, but I don’t think we ever planned on adding support for that anytime soon. Sigh.

Then there’s the other trouble, with the non-linked libraries in freebsd-lib due to the way they are built in standard FreeBSD (there aren’t the deps built at the time yet).

I suppose that adding support for --as-needed on Gentoo/FreeBSD would be a major hassle, and now I understand why KDE decided not to enable it on FreeBSD by default.

Nonsensical hacks: why I find kdenewldflags stupid

I see more and more people that use hacked kde eclass to add this mystique “kdenewldflags” useflag. What that is supposed to do is quite obvious, the —enable-new-ldflags option that KDE’s configure accepts. Still this is stupid.

Now, I’m not the kind of person to say that something is stupid just because I don’t like it, or I think it’s a bad idea. This is stupid simply because people enabling that have no damn clue of what is supposed to happen, and the same applies for the people adding that hack.

Let’s try to analyse that flag:

dnl Check if the linker supports --enable-new-dtags and --as-needed
AC_DEFUN([KDE_CHECK_NEW_LDFLAGS],
[
  AC_ARG_ENABLE(new_ldflags,
                AC_HELP_STRING([--enable-new-ldflags],

    [enable the new linker flags]),
        kde_use_new_ldflags=$enableval,
        kde_use_new_ldflags=no)

  LDFLAGS_AS_NEEDED=""
  LDFLAGS_NEW_DTAGS=""
  if test "x$kde_use_new_ldflags" = "xyes"; then
       LDFLAGS_NEW_DTAGS=""
       KDE_CHECK_COMPILER_FLAG([Wl,--enable-new-dtags],
                [LDFLAGS_NEW_DTAGS="-Wl,--enable-new-dtags"],)

       KDE_CHECK_COMPILER_FLAG([Wl,--as-needed],
                [LDFLAGS_AS_NEEDED="-Wl,--as-needed"],)
  fi
  AC_SUBST(LDFLAGS_AS_NEEDED)
  AC_SUBST(LDFLAGS_NEW_DTAGS)
])

this is the code triggered by ./configure -enable-new-ldflags that is what kdenewldflags useflag passes.

Do you see something familiar? Yes: the -as-needed flag I wrote so many times about, and that I’m trying to make acceptable for public consumption since a few months now.

So half of what the useflag do is to enable asneeded support, but in a way that is not understandable by ebuild/eclass code, so that filtering and eventually needed fixes aren’t triggered, which is bad.

And what about -eanble-new-dtags? Which immense performance improvements can it give you? None. Niet. Nada. That flag has nothing to do with the generated code, so it does not change performances. What it does is related to the internal structure of ELF files. From the man page:

> This linker can create the new dynamic tags in ELF. But the older ELF systems may not understand them. If you specify enable-new-dtags, the dynamic tags will be created as needed. If you specify dis-able-new-dtags, no new dynamic tags will be created. By default, the new dynamic tags are not created.
> Note that those options are only available for ELF systems.

So one might say that they want the new ELF features, even if they probably have no idea what they are used for (in fact, they are only internal symbols used by the linker and the loader, nothing more, nothing less). This will categorise those people together with people adding enable-new-dtags to their LDFLAGS.

But here enters the part that make the whole thing completely stupid: Gentoo’s binutils are patched to force the new dtags generation! Unless you pass the disable-new-dtags flag, binaries created with our binutils will always use the new dtags.

So to summarise: -Wl,–as-needed is better passed via LDFLAGS, as that way we can handle it in ebuilds. -Wl,–enable-new-dtags is pointless, useless and a stupid idea do pass (makes you look like a moron to developers’ and power users’ eyes). kdenewldflags is the pointless hack ever, and anybody using it should be ashamed of himself (half-joking, just half, really).

So please, do me a favour, stop using that stuff, don’t think that we in KDE herd are silly developers that tries to hinder innovation. We know when it’s time for something, and it will never be time for kdenewldflags.

Summing up the binutils trouble

Let’s sum up the binutils trouble with KDE and with other bugs too.

For a bug in 2.16.92 and 2.16.93 versions of binutils, the –as-needed flag ended up doing something more than is documented, instead of simply skipping DT_NEEDED entries, it also discarded the search path for the libraries passed in command line that get discarded.

If from one side this can be seen as a correct behaviour, this broke with almost every build system, like for instance everything using libtool. It broke in the sense that it ended up looking up the libraries installed in the system rather than the ones just build, failing to find them if they weren’t installed and cross-linking them if they were. The result is not good.

Luckily there is a patch laying in binutils-devel mailing list and it has been committed hopefully for 2.17. In the mean time you have either to cope with the problem or simply use my overlay and use binutils that are there. They are already patched for -Bdirect and -hashvals support (the latter more to avoid breakages).

I might end up closing some bugs pointing to this blog post as it’s boring to repeat the same stuff too many times ;)