On Tue, Feb 21, 2012 at 7:51 PM, David Sommerseth <openvpn.l...@topphemmelig.net> wrote: >> No there is none. Unlike other dependencies autotools dependencies are >> of development machine. You should create tarball on newer machine >> then compile it on the target platform. Target platform may not have >> autotools installed at all. >> >> The new build system will support >=autoconf-2.60, automake>=1.10, >> libtool>=2.2 > > That is not how James does his builds, from what I've understood. He > does builds in his own compile farm straight from source repositories. > James might just as well pop up NACKing things if these changes breaks > his tool chain. To put is simple: We are not allowed to break his > environments.
> >> Again, from experience generating tarball using these versions tends >> to work well on very old platforms. > > That's good, which can solve RHEL4 issues in a nice way. But I expect > James to do plenty of RHEL5 builds in the future, so there is noway we > are allowed to break this. I guess we should ask James. Adding him (at least his old address). Hello James, Can you please share your build environment so I know the impact? In all my build environments I check out the source at central build station, autoreconf, configure, make dist and then ssh the tarballs to targets for building. What exactly is your process? Supporting old autotools results in ugly hard to maintain implementations. More productive is to help fixing the build environment. > > On the RHEL5.7 base, libtool-1.5.22 is the base version. This is supported but none for Windows... I think it is sufficient. Alon.
