On Mon, Sep 6, 2010 at 9:34 PM, Magnus Fromreide <[email protected]>wrote:
> On Mon, 2010-09-06 at 08:02 +0200, Bart Van Assche wrote:
> > On Sun, Sep 5, 2010 at 9:12 PM, Magnus Fromreide
> > <[email protected]> wrote:
> > The attached diff is from head after regeneration of configure
> > and
> > net-snmp-config.h.in.
> >
> > I would like to see it (or an updated version) applied before
> > the next
> > release is done, is that possible?
> >
> > Hello Magnus,
> >
> > Which bugs are introduced in the configure script by applying this
> > patch ?
>
> The reverse of the bugs fixed from 2.63 to 2.65, obviously. As a small
> consolation the bugs that were introduced over that same time span are
> removed, consider the following from te NEWS file for 2.66:
>
> ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and
> AC_TYPE_INT64_T work again. Regression introduced in 2.65.
>
> There is of course the following from 2.65 as well...
>
> ** The AC_TYPE_UINT64_T and AC_TYPE_INT64_T macros have been fixed to no
> longer mistakenly select a 32-bit type on some compilers (bug present
> since macros were introduced in 2.59c).
>
> > Wouldn't it be better to switch from autoconf 2.63 to autoconf 2.65 on
> > the trunk instead of applying this patch ?
>
> Possibly, but I would prefer to go to 2.67 as that is the latest from
> upstream. 2.65 and 2.66 both seems to have been a bit botched if you
> check the NEWS file.
>
>
> The reason to not do the switch now is that we have decided to use 2.63
> on trunk some time ago and doing that change at this time (rc2 just out
> of the door...) feels ill advised.
>
> > As far as I know autoconf 2.65 the default autoconf in most Linux
> > distros.
>
> Might be, but then distro autoconfs are usually a bad choice anyhow
> since they all tend to add a different set of patches and our goal is to
> make it possible for all of us to regenerate those files without changes
> to them and regardless of the platform used to do development on.
>
> Additionally, and unrelated to all other things, net-snmp-config.h.in
> need to be regenerated regardless of the configure version as it is out
> of date with regards to the source right now, but that part of the patch
> is something I assume you are not having anything against.
>
Given the above, I'm voting +1 for the whole patch. But since this patch
affects the configure script, unfortunately that means that all platform
tests will have to be repeated.
Bart.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
