gnulib is an interesting way to make sure that software is written with more portability concern in mind, and works quite fine, usually. Unfortunately this is not always the case. In the last weeks we found at least two/three cases where gnulib was faulty and had to be fixed or updated. As updating gnulib from an ebuild is not a trivial way, the solution is usually an hack around it.
What I found now is a subtle problem with openat.c unit: basically it uses a va_arg call on mode_t type, but it warns you that you should rather use int, and that if the code is reached the program will abort.
I’ve prepared a patch for that, by looking at update gnulib code, and CVS’s CVS is already updated with a newer version of that unit that doesn’t present the bug. Unfortunately, it’s probably not the only software using it. I’ll see to prepare an automatic check for it with bashrc but I can’t say I’ll be able to do one working…
Also, ruby has some weird way to deal with FreeBSD/DragonFly systems, and I’m not actually sure why that is done. I’ll see if I can handle it in a decent way so that we have linux-style linking on Gentoo/FreeBSD at least.
