Do convert multiple libpath references

[Olf0]

This is on top of MR #221, so each step can be well tested, separately.

[Olf0]

IMO it is preferable not to squash these two commits, in order to keep the code changes comprehensible and traceable.

[nephros]

Please rebase on master (which now contains #221).

[Olf0]

Please rebase on master (which now contains #221).

Oh "shoot" … right into my own foot.
The need to rebase is something I usually try to avoid, but missed to think about it when creating these MRs (#221 & #222) as an obvious consequence. It is nice, that GitHub automatically switches the base, when it had been a branch, which was merged, but that is where the automatisms end.
I did not consider that, because for the reviewing work and the (usually very) small commits I create, working with the GitHub web-frontend is much more convenient for me, so this is what I use. Hence I do not have any of this locally (well, a git clone would resolve that), have never performed a re-basing, an am not keen on doing this and learning how to do this properly right now. What I would have liked to try, was rebasing at the GUI: I just tried that approach at my private "fork", but before I get to the point to choose the "rebase" pull-down option of the "merge" button, I am forced to resolve the conflicts manually (i.e., rebase manually). O.K., at least I learnt one action / route to avoid.
Thus the two options at your choice are, either I pose a new MR based on current master (a Copy&Paste manual rebasing) ore you rebase the two commits b1fea73 and 2a1f08b properly (at the command line). Either way is fine, it is just a few lines.

Oh heck, found an error in commit 2a1f08b, hence I just did the Copy & Paste while fixing the flaw, creating MR #225.

[Olf0]

Delete this stale branch and PR (#222), because it was superseded by the merged PR #225.