Fix for CVS build system build issue

[CeleSEQ]

There are two parts to the cycle. The partial patches that are done by developers to get it sort of working while the rest gets figured out, and the next "release" of the software. I would agree that an easier build system would be nice for the latter (and I think it is in fact happening with some people configuring the various build engines.) But for the former, the partial patches -- that belongs in the developer's domain and does not need to be published beyond these forums. People who are not develpers are welcome to follow along and try and do thier own patching, but I don't think you will find much support for supporting non-devs with the partial releases.

Amen. Building from CVS is an unsupported exercise imo. Wait for releases or at least for the packagers.

[Dedpoet]

FWIW, I'm still running RH9 and upgrading autoconf, automake, and libools to the versions in serberus' post got rid of the build errors for me.

I need to get Gentoo back on this laptop - I miss emerge...

[Cryonic]

The only rant I have concerns this rpm package install business. If the purpose of this stuff is to try to make change management easier so you don't have to be a rocket scientist, they surely failed. RPM sucks as bad as SMP 4 did on the IBM mainframe (I was a mainframe O/S support programmer in a previous life and had to apply patches to MVS). The rpm for autoconf ran just fine and installed cleanly, but the version 1.7.9 rpm of automake for RH8 was just horrible. It said it installed correctly, but I kept getting version 1.6.3 when I did "automake --version". It turns out that the package installer puts the binary executable files "automake" and "aclocal" in /usr/bin as "automake-1.7" and "aclocal-1.7". There were also files called "automake-1.6" and "aclocal-1.6" which were identical to the existing binaries in the directory named just "automake" and "aclocal". I ended up having to manually delete "automake" and "aclocal", and then clone "automake-1.7" and "aclocal-1.7" as "automake" and "aclocal", creating in effect what we used to call an alias name in mainframe lingo. The RPM should have done that automatically, if it was really trying to keep multiple versions of the binary executables in /usr/bin (a very bad practice I might add).

That is normal for RH to deal with multiple versions of certain binaries. What you probably deleted were a bunch of symlinks from the base automake/autoconf to the specific version. I see the same thing for vim, mozilla, qt, etc... Files get placed in specific folders with the version name as part of it and then symlinks are put in place. You could also set aliases for the files before you begin the build to prevent breaking other stuff that might have depended on the older tools.