A reminder to @midipix to "wrap strdup in slbt_strdup -- to avoid leaking of small memory chungs upon error".

See slibtool_errinfo_impl.c:37.

The leak I saw the other day is probably one related to some recently added code (rlibtool mode: derive ar and ranlib from the located libtool script). Fixed in commit 4964fd6.

As far as erri->eany and strdup(), we've been freeing those as needed from the very beginning: see slbt_driver_ctx.c:882.

Let's keep an idea on that then, as we might be missing something. Closing for now since valgrind does not show any leaks in none of the tested scenarios.