4 ms·
One small problem with this is that autoconf is not backwards-compatible. There are projects out there that need older autoconf than distributions ship with.
by nolist_policy 3y ago
One small problem with this is that autoconf is not backwards-compatible. There are projects out there that need older autoconf than distributions ship with.
- rwmj 3y agoThere are, and they need to be fixed.
- cesarb 3y agoThe test code generated by older autoconf is not going to be work correctly with newer GCC releases due to the deprecation of implicit int and implicit function declarations (see https://fedoraproject.org/wiki/Changes/PortingToModernC https://fedoraproject.org/wiki/Changes/PortingToModernC), so these projects already have to be updated to work with newer autoconf.
- badsectoracula 3y agoTyping `./configure` wont work but something like `./configure CFLAGS="-Wno-error=implicit-function-declaration"` (or whatever flag) might work (IIRC it is possible to pass flags to the compiler invocations used for checking out the existence of features) without needing to recreate it. Also chances are you can shove that flag in some old `configure.in` and have it work with an old autoconf for years before it having to update it :-P.
- Too 3y agoEasily solved with Docker. Yes, it sucks to add yet another wrapper but that’s what you get for choosing non backwards compatible tools in the first place. In combination with projects that don’t keep up to date on supporting later versions.
- account42 3y agoA yes, let's replace "binary" blobs in release archives with even bigger blobs of mistery goo.
- pajko 3y agohttps://www.gnu.org/software/autoconf-archive/ https://www.gnu.org/software/autoconf-archive/