This can create a libtool version conflict when the version of libtool used to generate the files in the repo differs from the version installed on the host. Needless to say, it breaks the build. This problem affects both libgpg-error and libgcrypt, maybe other gnupg projects too.
You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.
If you think any file is not tracked in the repo, please let us know.
The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.
If you want to make the official policy "only the maintainer updates the autotools..." then that's fine, but for folks like me that have no choice life would be a bit easier if autogen.sh did what it supposed to.
Forgive me. I was biting my tongue.
Serious though, for me and numerous other maintainers you'd be doing us a favour if you got whatever changes gpg-error depended on upstreamed and started depending on the new version once it's released.
We expect that the pre-patched version supplied by the system will be picked up and are a bit disappointed when it's not. Having to deal with projects that have decided to fork things like libtool is a headache.
For now I'll live with patching autogen.sh to include a call to libtoolize, which does the trick for me.
I merely said, that we won't replace libtool by the upstream version because that lacks other important changes we need. Upstream was not willing to integrate our changes for Windows support and also introduced a lot of other regressions as well as dropping support for some platforms. Thus we need to maintain our version.
So what are the changes required for your platform and what is the cpu-vendor-os string (config.guess output)?