A (possibly too naive) resolution would be a symlink ...

Having said this I checked the one and only /usr/x86_64-slackware-linux/ directories (on all my Slackware instances as well as on alien's live CD) and found that their bin/ and lib64/ directories are empty.
So what is the problem?

Hi @Pat
on mine I still have automake-1.16.5 and since feb 10 autoconf-2.71 and feb 11 Just tested gtk+2-2.24.33 compiled no host mismatch..
Other than the usual checking build system type... x86_64-blade64-linux-gnu same for host..
should work for slackware too. autoconf-2.71
Tested because last compile I had automake-1.16.2 and autoconf-2.71.

autoconf-2.71 doesn't work to build oprofile and then binutils, which is rather annoying.
and for gtk+2 PV explained it.

as said gtk2 I don't get the host mismatch

compile binutils then oprofile and those are compiling for me ..

ok, i'm talking of building from scratch slackware (SFS), you build packages in a certain order:
- binutils (without oprofile)
- oprofile (later)
- binutils with oprofile: it's at that step that the incompatibility of autoconf-2.71, 2.72a or 2.72b or git version exists and you're stuck, and can't go on.

1 members found this post helpful.

ah weird cause what I have I built from scratch 32bit to 64 and made it multilib(fully, my gcc is both) (compile 32bit on the 64 -m32). but that was long time ago so yeah know about the order.. I used lfs multilib but I did change a lot back then to fit slackware style.. pus I used 2 dirs to compile into since I didn't have another drive to do their partition way etc..
when I did that with the 2 dirs it was to build the tool chain then chroot in and build it to the packages.
can you send me a log of the build(binutils)

also for binutils-2.37 23 patches

I removed autoconf >= 2.71 from the development tree of SFS for that reason, I couldn't solve that problem.

I'll see when I can do it.

ah I remember why, I bet its this
# Thanks to Fedora:
# Dependencies are not set up to rebuild the configure files
# in the subdirectories. So we just rebuild the ones we care
# about after applying the configure patches
pushd libiberty
autoconf
popd
pushd intl
autoconf
popd
I removed that on mine would need autoconf-2.69
never got around to have both

You can also try to build SFS with the dev branch, by replacing the autoconf by the version you want (2.71) and see that you'll be stuck in the middle of the build_list2, and see the messages of errors.

ok heres what I did with slacks
I used the same way as firefox with autoconf-2.13 but I only have it used for the push and the rest is building normal with 2.71
had to edit the build-deps.sh https://pastebin.com/p5gqNjEg
and rename the autoconf.SlackBuild and remove unneeded etc ..
binutils.SlackBuild
# Build or unpack build-time dependencies:
. ./build-deps.sh

TMP=${TMP:-/tmp}

pushd libiberty
$TMP/binutils-build-deps/usr/bin/autoconf-2.69
popd
pushd intl
$TMP/binutils-build-deps/usr/bin/autoconf-2.69
popd

binutils/build-deps/autoconf/
autoconf.build
https://pastebin.com/Vx2zRkWB

I don't call this build with autoconf-2.71 as the sole autoconf package.

I don't know whether they still do it, but when I was playing with OpenBSD a few years ago I notice they actually parallel install multiple versions of autoconf because of these incompatibility issues so that individual ports could run against the one they needed.

I've always considered autotools a case of "cure is worse than the disease". It's really no wonder that projects are switching to meson.

yeah parallel build would work too.. but just have to use --program-suffix=-2.69 \

pushd libiberty
autoconf-2.69
popd
pushd intl
autoconf-2.69
popd